search

vivekrajenderan / simplesamlphp

Automatically exported from code.google.com/p/simplesamlphp
Other
0 stars 0 forks source link

Export NameIDFormat in metadata according to configuration #604

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
It should be possible to export the list of supported NameID formats in the 
generated metadata without explicitly telling with the NameIDFormat option 
(which currently supports only one format). By just looking into the NameID 
generation filters (1) generally available, an IdP should be able to tell which 
formats it supports, so there's no need to manually specify them.

The current configuration mechanism is error prone and may lead to 
configurations such as an IdP claiming to support only the persistent format, 
but actually not supporting it because there's no generation filter in place. 
The NameIDFormat option could be kept as an array that filters the list of 
formats supported, namely to remove transient support.

On the SP side, the NameIDFormat directive should be an array specifying the 
list of formats supported, mainly for metadata generation.

Original issue reported on code.google.com by jaim...@gmail.com on 9 Dec 2013 at 3:27

GoogleCodeExporter commented 9 years ago

Original comment by jaim...@gmail.com on 27 Jan 2014 at 12:10

GoogleCodeExporter commented 9 years ago 
I think looking at NameID generation filters may be challenging, at least as 
they are designed now. What exact NameIDs can be generated depends on the 
general authentication processing filters (in "authproc.idp" in config.php), 
the filters configured in the IdP metadata, and the filters in SP metadata. In 
addition, it depends on the user's attributes.

The filters, as they are currently designed, are not meant to communicate any 
information about what formats they _may_ generate. They are only designed to 
attempt to generate NameIDs, and store them in the state array.

I do not think we should add an additional function to the NameID filters in 
order to allow them to communicate what they may generate. It would be a 
drastic change from the way filters are currently designed. Now they are just 
pieces of code that should run in some sequence in order to navigate the 
authentication process from login to authentication response generation.

I think the more proper solution would be to allow the IdP to include multiple 
entries in the NameIDFormat option in idp-hosted metadata, and use that option 
only for generating the XML IdP metadata.

The NameIDFormat in sp-remote metadata should probably be some sort of policy, 
listing which NameIDFormat values the SP is allowed to receive, but that will 
probably break some SPs. I would therefore avoid that change until SSP 2.0.

Original comment by olavmrk@gmail.com on 28 Jan 2014 at 12:29

GoogleCodeExporter commented 9 years ago

Original comment by jaim...@gmail.com on 20 Feb 2014 at 11:21

GoogleCodeExporter commented 9 years ago 
Closing the issue here, moved to:

https://github.com/simplesamlphp/simplesamlphp/issues/51

Original comment by jaim...@gmail.com on 27 Feb 2014 at 7:37