Match "Requested Attributes" from metadata to ARP

[maartenk]

The requested attributes for an SP can be set in the SAML metadata. Currently these values are not handeld by Janus

As a feature request: the Requested Attributes to be concept ARP for that specific SP, so we don't need to set those manually anymore (just check/adjust them).

[pmeulen]

Now that we store the ARP in the SP connection instead of separately, this should be much easier to implement.

@maartenk how many SPs (that you import) publish this information?

[maartenk]

@pmeulen The exact amounts i'm not sure, but basically every (new) edugain SP as well as every new SP which provide the requested attributes correctly via SURFconext Registration form.
Preferably both the required as well as the optional items. (Based on the the isRequired setting).

<!-- example for the required attribute: mail -->
<md:RequestedAttribute FriendlyName="mail"
Name="urn:oid:0.9.2342.19200300.100.1.3"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
isRequired="true" />

[relaxnow]

Preferably both the required as well as the optional items. (Based on the the isRequired setting).

ARP currently only have the power to filter attributes, not halt SSO because attributes are missing.
This would require some significant modifications to the APIs and EB.
Let's start with being able to import all RequestedAttribute elements into the ARP.

[thijskh]

Agreed. Blocking access based on (absense of) attributes is a different (but existing) project.

[maartenk]

On 12 mei 2015, at 23:07, Boy Baukema [email protected] wrote:

Let's start with being able to import all RequestedAttribute elements into the ARP.

Agree. That is what i aimed for.

[relaxnow]

I now have an initial implementation that uses all RequestedAttribute fields it finds in the first AttributeConsumingService and tries to make an ARP out of that.

Note that while I did do denormalization of OID to URN and the other way, the normalization that SSP has is not as good as the one EngineBlock has.

For instance on one test SP it was unable to see that the SP requested the SHO attribute because we use the URN and the SP had the URI in it's RequestedAttributes but SSP doesn't have the mapping for that.

Also you can't chose to NOT import the new ARP, much like Allowed Connections you'll always get it.

And we don't do anything with RequestedAttribute > AttributeValue elements, we just always do *.

And of course we don't do anything with isRequired.