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
Hi,
On the last DEV call we talked about moving to using type hints.
The typing module was added in Python 3.5, but as of today SATOSA still
supports Python 3.4.
I apologize if I missed it, but did we discuss stopping support for
Python 3.4? If so, when?
Thanks,
Scott
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
