- Satosa-dev - lists3.sunet.se

How to handle 3D model optimization and API loading for open-world games?

by ropeherohub .com

Body: Hey everyone 👋 I’m working on a small open-world superhero game project (something like Rope Hero) and trying to figure out the best way to handle 3D model loading and optimization through APIs. I’ve read a bit about using async data fetching for models and textures, but I’m not sure what’s the most efficient approach to keep things lightweight while maintaining quality. Does anyone here have experience with streaming 3D assets dynamically or managing API-based level loading in real time? Any tips or frameworks you’d recommend? Also shared a few related notes on this topic here → https://ropeherohub.com/ Would love to hear your thoughts!

1 day, 16 hours

3
2
0 0

Enjoy survival and creative modes on mobile

by krowncrafts01＠gmail.com

Enjoy survival and creative modes on mobile with <a href="https://mynecraftapkpro.com/minecraft-pe-apk/">mcpe apk</a>. Many also prefer minecraft download minecraft download minecraft download for quick setup.

1 week, 1 day

1
0
0 0

Configuration of response and attribute signing, and signing and digest algorithms

by ivan.kanak＠gmail.com

Hello everyone, I have been looking into PR #495 https://github.com/IdentityPython/pysaml2/pull/495 What the user needs is an option to configure the signing algorithm that will be used by the SP to sign an authentication request. This comes in hand with the digest algorithm and in extension what is entity that should be signed. What the proposed one line change does, is allows this value to exist in pysaml2 Config object. By itself, it does not affect anything in the code - it does not set the signing algorithm. It is only a placeholder for a value. Something else is supposed to look at that value, at the right time, and pass it as an argument to the appropriate function/method. This doesn't seem right. If it is in the configuration, then it should actually do something - it should affect the way the library behaves. Looking into this I stumbled upon some commits, made about a year ago, that implement some of this functionality for the IdP part: * 2aedfa0 - make both sign response and assertion configurable adds sign_assertion and sign_response options * bd4303a - Signing signature and digest algorithm configuration adds sign_alg and digest_alg options These are implemented in the SATOSA repository (see satosa/frontends/saml2.py the _handle_authn_response method). However, their configuration lies between the lines of the pysaml2 configuration (under service/idp/policy). This is wrong - each project should be responsible for its own configuration. The code that decides what should be signed and how, should live in pysaml2. If it is handled by SATOSA then it should be part of the SATOSA configuration and an override of the pysaml2 configuration. Moreover, it seems that this functionality was partially already there in pysaml2 in the first place. See the Policy class in saml2/assertion.py and its get_sign method. An option named 'sign' can be defined under the service/idp/policy part of the configuration, that defines an array of values that represent what should be signed, for example: service: idp: policy: sign: - response - assertion So now we have both the above 'sign' option, plus 'sign_assertion' and 'sign_response', which should do the same thing. What I would like to do is move the code introduced by the commits above into pysaml2: this will allow a consistent behaviour whether pysaml2 is used by SATOSA or some other project. Then the same options can be used by the backend too, which would satisfy the user request. Once that is done we can look into making the configuration work in one way. This is bigger than it looks. What happens now is that we define for example, that we want to use SHA512 as a sign_alg. This will be used when a authentication response is formed, but it is ignored when for example a logout request is to be created. This happens because the configuration of what signing algorithm will be used is only implemented for the authentication response. There are two ways to fix this: - we either assume that a configuration option like 'sign_alg' is global, and as such, it affects the signing algorithm of anything that is to be signed - or we assume that it relates to the authentication req/response only (and in that case it shold probably be called authn_sign_alg or alike) and require new options for other kinds of signatures (logout_sign_alg, metadata_sign_alg, etc). The first solution requires that we find all places in the code use signatures and make sure they respect the configuration. I have already noted (a lot of) entry points to pysaml2 that should be looking into the configuration to derive the signing and digest algorithm values. The second option is "easier" to work with, as it allows for an incremental implementation of this request. The second approach is also more flexible for the end user, but at the same time more complex as it requires more configuration values to be set. Ofcourse we can have both, use an option like sign_alg to defined the signing algorithm, and use "suboptions" like authn_sign_alg to override the sign_alg setting where needed. I hope this makes sense (even though it mixes at least four configuration options together). If you have any comments, I'd like to hear. Cheers, -- Ivan c00kiemon5ter Kanakarakis >:3

1 week, 1 day

11
13
0 0

How to handle 3D model optimization and API loading for open-world games?

by ropeherohub .com

Body: Hey everyone 👋 I’m working on a small open-world superhero game project (something like Rope Hero) and trying to figure out the best way to handle 3D model loading and optimization through APIs. I’ve read a bit about using async data fetching for models and textures, but I’m not sure what’s the most efficient approach to keep things lightweight while maintaining quality. Does anyone here have experience with streaming 3D assets dynamically or managing API-based level loading in real time? Any tips or frameworks you’d recommend? Also shared a few related notes on this topic here → https://ropeherohub.com/ Would love to hear your thoughts!

1 month, 2 weeks

1
0
0 0

oidcop frontend

by giuseppe.demarco＠unical.it

Hi, I developed this during a low-effort sprint of 6 days https://github.com/IdentityPython/SATOSA/pull/378 It's a working draft. Waiting for revisions and contribution from our community I'll go ahead with unit tests and all the tasks described in the PR. Any reaction, idea, suggestion is appreciated by right now, feel free to put your spells on top of my branch :) best regards -- ____________________ Giuseppe De Marco Centro ICT d'Ateneo Università della Calabria 87036 Rende (CS) - Italy Phone: +39 0984 496961 e-mail: giuseppe.demarco at unical.it -- ------------------------------------------------------------------------------------------------------------------ Il banner è generato automaticamente dal servizio di posta elettronica dell'Università della Calabria <http://www.unical.it/5x1000>

4 years, 3 months

1
0
0 0

Vulnerabilities affecting pySAML2 and forthcoming release

by ivan.kanak＠gmail.com

Dear users of IdentityPython, this is a heads-up about two vulnerabilities affecting pySAML2. Software that uses pySAML2 is indirectly affected, too (ie, SATOSA). The issues were reported to the IdentityPython incident-response mailing list and we have been working on a mitigation. A new version of pySAML2 that includes the fixes will be released on Wednesday 20th of January between 13:00 CET and 17:00 CET. We urge everyone to be prepared to update their setup to the latest version. Kind regards, Ivan Kanakarakis on behalf of the incident-response team

4 years, 10 months

1
3
0 0

controlling NameID format and value sent to SP

by skoranda＠sphericalcowgroup.com

Hi, I have been asked off-list the same question by a couple of different people. The question is "how can I get SATOSA to send a specific NameID value and format to the requesting SP?" They usually ask after trying, in vain, to configure the SAML2 frontend and/or the SAML metadata for the SP to specify a particular NameID format (e.g. urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress). My reading of lines 339 to 353 in .../frontends/saml2.py is that there is no way to force, either through configuration of the frontend or in SAML metadata what format is used for NameID, nor what value is used. Rather what happens is that the frontend takes whatever values are set for internal_response.subject_id internal_response.subject_type and creates a NameID element object and passed it to pysaml2 to create the actual response. The only exception to that rule is if internal_response.subject_id is None, then pysaml2 is passed None, and it has code that then defaults to creating a transient NameID (which I argue is the most sensible thing it can do). So to my reading, the only and correct way to affect what the SATOSA SAML frontend sends for the NameID is to have a response microservice that sets internal_response.subject_id internal_response.subject_type before the frontend begins processing the response. The only alternative is to just accept what is passed through from the backend. Is my analysis correct? Thanks, Scott K P.S. I have been using a microservice(s) to set internal_response.subject_id internal_response.subject_type for quite some time and it works just fine.

5 years, 5 months

2
4
0 0

SAMLBackend and discovery initiated flows

by skoranda＠sphericalcowgroup.com

Hi, The current SAMLBackend actually allows "discovery initiated" flows. That is, a browser with no other state can invoke the URL endpoint for the SAMLBackend disco_response() as long as it passes in the entityID for the IdP to use for authentication in the query string. The backend will redirect the user to the IdP and consume the SAMLResponse when the browser returns. Such a flow does not make much sense for most deployments because after consuming the SAMLResponse and passing back to the frontend, the frontend (either SAML or OIDC) will fail because it doesn't know where to redirect the browser, since the flow did not originate or come through the frontend. The SAMLFrontend will fail with the well known but hated "UnknownError". I have a deployment where this is happening fairly regularly. It turns out it is because of users that have either bookmarked the discovery service or are opening/restarting browsers with tabs that were "paused" at discovery. Sigh. We will be (attempting) to educate users, but we also want to not allow "discovery initiated" flows and we want them to fail with a better exception and error message in the log files to assist help desk staff. Unfortunately I can imagine some deployment configurations where a "discovery initiated" flow might make sense and is "doable" (with enough microservices anything is doable). So I don't think we can just make the current behavior disallowed by default. Instead I have submitted PR 322 https://github.com/IdentityPython/SATOSA/pull/322 which adds the configuration option 'allow_discovery_initiated' for the backend. By default it is True to preserve the current (odd) behavior, but when set to False a flow that starts at the disco_response() endpoint will immediately fail with exception SATOSAStateError and message IdP discovery initiated flow not allowed Sorry for the long note, but I thought it better to explain in detail since the code changes themselves might not make the use case (or edge case) clear. Please let me know if you have any questions or concerns. Thanks, Scott

5 years, 8 months

1
0
0 0

Federeated domaian in AAD authenticate with IDP pysaml2 sample.

by gus.duarte＠gmail.com

Hi all, I configured a federated domain in my Azure AD tennant to be authenticated against an IDP based on pysaml IDP sample. When I try logging in https://portal.azure.com with an user at myfedereteddoaim.com, following error happens: AADSTS50008: Unable to verify token signature. The signing key identifier does not match any valid registered keys. Any suggestions? Thanks in advance. Regards.

5 years, 8 months

2
3
0 0

SaToSa support for new SAML subject identifiers

by niels.vandijk＠surfnet.nl

Hi all, Is there an existing implementation (or planned) implementation of the new SAML subject identifiers [1] ? [1] https://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/saml-subject… Many thanks, Niels -- Niels van Dijk Technical Product Manager Trust & Security Mob: +31 651347657 | Skype: cdr-80 | PGP Key ID: 0xDE7BB2F5 SURFnet BV | PO.Box 19035 | NL-3501 DA Utrecht | The Netherlands www.surfnet.nl www.openconext.org

5 years, 9 months

4
6
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Satosa-dev