search

janus-ssp / janus

Fully featured metadata registration administration module built on top of simpleSAMLphp.
Other
13 stars 8 forks source link

Match "Requested Attributes" from metadata to ARP #449

Open maartenk opened 10 years ago

maartenk commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

@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 commented 9 years ago

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 commented 9 years ago

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

maartenk commented 9 years ago

On 12 mei 2015, at 23:07, Boy Baukema notifications@github.com wrote:

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

Agree. That is what i aimed for.

relaxnow commented 9 years ago

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.