Hi,
I have a response microservice that needs some information that only the
frontend knows.
>From what I can tell, there is no way for the microservice to get a hook
into the frontend in order to gather the information.
Am I missing something?
Thanks,
Scott K
Hi,
To summarize:
- SATOSA_STATE in its original design is a straight link between SSO request and response. After the frontend created the Response the _save_state call will delete the cookie.
- To remember the selected IDP SATOSA_STATE across over the long term state can be kept by setting CONTEXT_STATE_DELETE=False
I think that it could make sense to separate short- and long-running state cookies. For my current use case (requiring a replay of the previous AuthnRequest during Response processing in the backend) I decided to create a separate cookie, which is in fact a key into a local Redis store. It has a life cycle different, longer than a straight Response, but not across SSO flows.
BTW, shouldn’t the proxy set HttpOnly and SameSite=Strict for SATOSA_STATE?
Cheers, Rainer
> Am 2019-06-05 um 00:27 schrieb Christos Kanellopoulos <christos.kanellopoulos at geant.org>:
>
> Hello,
>
> for question (b) indeed there is a point to do that. If one wants to keep state across authentication requests, then SATOSA needs to search for the cookie also in the AuthN request and load the context if it is found and it is valid. For example, in PR #234 we add the option to save the selected IdP in the cookie so that in the follow up AuthN requests SATOSA can skip the discovery. Having said this, it’s been a year since I touched that code so Ivan please correct me if I am wrong.
>
> Christos
>
> From: Rainer Hoerbe <rainer at hoerbe.at>
> Sent: Friday, May 31, 2019 12:42 PM
> To: Ivan Kanakarakis; Christos Kanellopoulos
> Cc: satosa-dev at lists.sunet.se
> Subject: SATOSA_STATE
>
>
> I summarized the handling SATOSA_STATE as discussed in Tuesday’s meeting in the attached diagrams. I have two questions:
>
> a) Is this picture correct?
> b) Is there any purpose in loading the context from SATOSA_STATE when an AuthnRequest is received?
>
> Thanks, Rainer
>
>
>> Am 2019-05-30 um 13:09 schrieb Ivan Kanakarakis <ivan.kanak at gmail.com <mailto:ivan.kanak at gmail.com>>:
>>
>>
>> On Wed, 29 May 2019 at 23:28, Rainer Hoerbe <rainer at hoerbe.at <mailto:rainer at hoerbe.at>> wrote:
>>
>>>
>>> Side topic: state/flow – need to discuss FE/BE state, long-running state (SATOSA is stateless). Shall we have policies around this? Need to describe use cases.
>>>
>>> Use case from Christos and Rainer require extra exchanges during the proxy flow, requiring to preserve state for the whole flow.
>>>
>>> Christos: Cookie deletion is removed with PR #234!
>>>
>>
>> It is now configurable ;)
>>
> <authnrequ_state.png><authnresp_state.png>
On Fri, 31 May 2019 at 12:37, Rainer Hoerbe <rainer at hoerbe.at> wrote:
>
> I summarized the handling SATOSA_STATE as discussed in Tuesday’s meeting in the attached diagrams. I have two questions:
>
> a) Is this picture correct?
Looks right to me. btw, I think those diagrams are really helpful,
thanks for making them ;)
>
> b) Is there any purpose in loading the context from SATOSA_STATE when an AuthnRequest is received?
>
In general, no; it is there as part of the generic process (it does
not specialize for the authn-request flow).
But, one can use this to make some special things happen, ie use the
cookie for feature flags.
--
Ivan c00kiemon5ter Kanakarakis >:3
Hi,
I require the SATOSA SAMLFrontend to assert the following XML for
eduPersonTargetedID as part of an <AttributeStatement>
<Attribute FriendlyName="eduPersonTargetedID"
Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<AttributeValue>
<NameID
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
NameQualifier="https://proxy.my.org/idp/satosa"
SPNameQualifier="https://service.my.org/sp/shibboleth">
1088878806
</NameID>
</AttributeValue>
</Attribute>
Here the value 1088878806 for <NameID> is to be taken from a database (I will
be using an LDAP directory, but in general it is being pulled from some
storage), the NameQualifier is the entityID for the SATOSA proxy IdP frontend
(the SAMLFrontend instance), and the SPNameQualifier is the entityID for the SP
that sent the <AuthnRequest> to the SATOSA proxy IdP frontend.
Has anybody configured the existing SATOSA and pysaml2 code to assert such
XML? If so can you share some details of your configuration?
If not, is anybody using modified SATOSA or pysaml2 code that has not been
contributed yet to assert such XML and is willing to share and/or collaborate
on getting it contributed (relatively quickly)?
Thanks,
Scott K
P.S. I am fully aware that there are reasons to deprecate the use of
eduPersonTargetedID. For this particular deployment I need to assert this
attribute for the time being using SATOSA.
Hi,
Am I correct that the SATOSA SAMLBackend class currently has no way to
dynamically set "force_authn" so that the SAML authn request sent to the
authenticating (campus) IdP includes the forced reauthentication flag?
Thanks,
Scott K
Hi,
For a SAML proxy deployment (no OIDC here yet) I need a sophisticated
attribute release policy that should be largely driven by SAML metadata
entity categories. The policy is essentially to release the union of
attributes for each of the entity categories REFEDs R&S, CoCo, and a few
others to which the entity belongs.
Later I am sure there will need to be per-entity adjustments (there
always are...).
Have other deployments already implemented tooling to implement such a
policy?
I don't see that the SAMLFrontend (or its sub classes) has the requisite
functionality. Or that pySAML2 has it--the policy based functionality
appears to mostly be around statically configured filtering and not
driven by SAML metadata. Am I missing existing functionality?
If I need to develop the functionality, then I am wondering if it is
best done by implementing a response microservice(s), or to evolve the
SAMLFrontend code?
Thoughts?
Thanks,
Scott K
Hi,
I just submitted a first draft of a PR for the SAMLUnsolictedFrontend
class.
The class provides all of the functionality of the SAMLFrontend class
but also enables an "unsolicited" endpoint that can be used to initiate
a SAML flow using a proprietary set of query string parameters that are
not part of any SAML standard but follow closely similar functionality
from the Shibboleth project.
For example, one might do a GET to (line breaks added and query string
not encoded for clarity)
https://myproxy.my.org/saml2/unsolicited?\providerId=https://mysp.my.org/sp/shibboleth&target=https://mysp.my.org/secure&shire=https://mysp.my.org/Shibboleth.sso/SAML2/POST&discoveryURL=https://mydisco.my.org/
This will cause a flow where
https://mydisco.my.org/
is used for IdP discovery followed by a SAML <Response> being sent to
the SP with entityID
https://mysp.my.org/sp/shibboleth
at the ACS URL
https://mysp.my.org/Shibboleth.sso/SAML2/POST&
and with relay state
target=https://mysp.my.org/secure&
The providerId query string is required. The others are optional.
To prevent being an open relay the SP entityID must match one found in
the trusted metadata, the ACS URL must match one found in the trusted
metadata for the SP, the relay state URL must have a scheme, host, and
port that matches the ACS URL, and the discovery service URL must be
whitelisted in the configuration. The relay state URL condition could be
more sophisticated.
The functionality and the names of the input query parameters are
inspired by the Shibboleth IdP functionality described at
https://wiki.shibboleth.net/confluence/display/IDP30/UnsolicitedSSOConfigur…
and the SP functionality for discoveryURL described at
https://wiki.shibboleth.net/confluence/display/SP3/ContentSettings
I am not married to the names of the query parameters--aligning with the
Shibboleth project seems to make some sense, but they are using 'shire'
for historical reasons and a better name would be something like
'acs_url' or even just 'acs'.
The configuration is the same as for the SAMLFrontend base class, except
that you add something like
unsolicited:
endpoint: unsolicited
discovery_service_whitelist:
- https://mydisco.my.org/
With that configuration the endpoint is exposed at <backend name>/unsolicited
If instead you had
unsolicited:
endpoint: foo/bar
discovery_service_whitelist:
- https://mydisco.my.org/
then it would be exposed at <backend name>/foo/bar
I have not written any tests yet nor updated the documentation. If
nobody raises any objects I will proceed with doing that.
All input welcome.
Thanks,
Scott K
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
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
