April 2019 - Satosa-dev - lists3.sunet.se

by skoranda＠gmail.com

Hi, I know it has been talked about as "doable", but has anybody already deployed SATOSA with a response microservice that implements a "step-up" flow to leverage a second factor (like Duo) when the authenticating IdP does not assert that MFA was used? If so, are you considering sharing it and/or contributing it to the code base? If not, but you are considering such an implementation/deployment, can you indicate if you are interested in collaborating on the development and testing? Thanks, Scott K

5 years

5
6
0 0

[microservice] Decide backend by target entity ID

by giuseppe.demarco＠unical.it

Hi to everybody, I developed a microservice that can map specific SaToSa backends to specific target entity id. A configuration example can be this: ```` module: satosa.micro_services.custom_routing.DecideBackendByTarget name: TargetRouter config: target_mapping: "http://idpspid.testunical.it:8088": "spidSaml2" "http://strangeIDP.testunical.it:8081/saml2/metadata": "strangeSaml2" ```` I needed a backend routing based on the target entity ID because I have some SAML2 IDP that only accepts highly customized authn request and metadata. An example would be SPID italian federation, through which my organization will federate soon with SaToSa. Another example could be the need to use different configurations, like enc and digest algorithms, depending by target IDP. I was looking into DecideBackendByRequester microservice but soon I realized that it was made for different goals, in it the subjects are the requester entity ID and not the target entity ID. As you can see in https://github.com/IdentityPython/SATOSA/pull/220 I made a single branch to pull only this feature. I'm also curious about SaToSa milestone, which are the features in development status, which will compose the next release and another question about the possibility to have a dev branch to do PR on it. I don't know if this microservice could sound useless to you, I searched a lot before programming it and I hope to have done a middleware that could be usefull for the SaToSa community. Hope to hear your comments soon

5 years

1
1
0 0

More flexible discovery service process for SAML backend?

by skoranda＠sphericalcowgroup.com

Hi, Right now the saml2.py in src/satosa/backends/ has def disco_query(self): """ Makes a request to the discovery server :type context: satosa.context.Context :type internal_req: satosa.internal.InternalData :rtype: satosa.response.SeeOther :param context: The current context :param internal_req: The request :return: Response """ return_url = self.sp.config.getattr("endpoints", "sp")["discovery_response"][0][0] loc = self.sp.create_discovery_service_request(self.discosrv, self.sp.config.entityid, **{"return": return_url}) return SeeOther(loc) Essentially this restricts the flow to one and only one IdP discovery service that is configured statically. I propose that this method be enhanced so that it can inspect the context and internal data and if it finds a URL for the discovery service to use it overrides what is in the configuration. Then one can configure a request microservice that uses some logic to set the URL for the discovery service, such as which SP the authentication request came from. Since the comment for the method already includes a mention of the context and internal data, I suspect this functionality was designed but never implemented. Any objections to me implementing it? Any other comments or input? Thanks, Scott K

5 years

2
1
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Satosa-dev April 2019