Closed GoogleCodeExporter closed 9 years ago
Original comment by jaim...@gmail.com
on 27 Jan 2014 at 12:10
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
Original comment by jaim...@gmail.com
on 20 Feb 2014 at 11:21
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
Original issue reported on code.google.com by
jaim...@gmail.com
on 9 Dec 2013 at 3:27