Am 2019-05-06 um 14:08 schrieb Scott Koranda
<skoranda at gmail.com>:
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?
pysaml2 had entity-category based AR since early on, and
requested-attribute-based release was implemented later. The
documentation seems however to be limited to static restrictions:
https://github.com/IdentityPython/pysaml2/blob/master/docs/howto/config.rst…
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?
It should work via Metadata, therefore it should go into the frontend.
Peeking into assertion.py
<https://github.com/IdentityPython/pysaml2/blob/master/src/saml2/assertion.py>
I see quite some filtering mechanisms - with some guessing and trying
that could be a starting point.
Thanks. I have found the class Policy in assertion.py and then the
details in src/saml2/entity_category and I am working through the code
now to try and understand what it is doing.
If I manage to do that I will submit a PR on the documentation.
IIRC there was a long thread about AR on this list
some time ago,
discussing the semantics of combining EC and requested-attributes
based metadata. Maybe thats worth digging out.
I will plan to do that because I am concerned about this comment in
assertion.py for the method filter() on the class Policy:
""" What attribute and attribute values returns depends on what
the SP has said it wants in the request or in the metadata file and
what the IdP/AA wants to release. An assumption is that what the SP
asks for overrides whatever is in the metadata. But of course the
IdP never releases anything it doesn't want to.
I think this is now "wrong", in the sense that the community has decided
that an entity category should not be overridden by what the SP asks
for. This allows an entity in eduGAIN to be tagged with an entity category
(say R&S) and get what it needs from those IdPs that support the entity
category, but then to minimally signal to those IdPs that do not support
the entity category that it needs somethings.
So an SP in eduGAIN tagged with R&S can get all of the R&S attributes
from supporting IdPs, but then only put in the metadata a request
for ePPN (or eventually the newer SAML persistent non-targeted identifier)
to help persuade IdPs that do not support R&S to at least release that attribute.
So I think there is going to be a need to toggle that override behavior.
Thanks,
Scott K