Extraction of contacts and other built-in metadata information
Description
Environment
is related to
Activity
Scott Cantor February 13, 2012 at 3:29 AM
Closing with documentation written.
Scott Cantor January 27, 2012 at 2:48 AM
http://svn.shibboleth.net/view/cpp-sp?rev=3562&view=rev
Plugin supports language-aware extraction of errorURL, organization elements, and contacts.
Scott Cantor September 9, 2011 at 3:48 AM
Our thinking, or at least my thinking, has largely moved into alignment with the reporter here. The boarding notion has failed completely due to the overhead of implementing it, and I've shifted totally in favor of "detect and report" at the SP.
https://shibboleth.atlassian.net/browse/SSPCPP-245#icft=SSPCPP-245 is about the main feature we need to do attribute validation at the SP, so I want to focus this issue on the contact extraction part. Instead of a loopback, I think having an extractor plugin that pulls out metadata information into meta-attributes is simpler.
Scott Cantor January 18, 2011 at 11:25 AM
Yes, basically I'm trying to assist in parsing the metadata.
Avoiding the selection of an IdP just means that you never use a federation level WAYF/DS, and you have a process whereby an IdP admin indicates to the application that the IdP is ready for use by the SP by verifying the right policy is in place. Then the IdP gets added to the local DS list. That's what we usually call a "boarding process". Of course, the alternative is the consent-based model but that also avoids the need for contacting the IdP admin.
Olivier Sal January 18, 2011 at 11:15 AMEdited
I realize that the SP itself cannot know something went wrong because it's an application concern. But the application could redirect the end user to a dynamic web page handled by the SP that would provide the expected behavior. Providing this feature at the SP would remove the burden of parsing the metadata for the application. The loopback handler you mention sounds like a good solution.
You mention that the SP should not allow the end user to select an IdP that does not support the necessary policy. How would you achieve that? It requires some kind of attributes negociation between the SP and IdP?
At our federation level we're also going an other direction to try solving this issue : we provide attribute-filters for all registered SPs. But not all IdP admins currently use them.
Thank you.
The usual issue with user attributes occurs when the IdP was not properly configured to release user attributes required by the SP-protected application. That's one of the most common issue and it's hard to make the user do the right thing to fix it. The best that can be done by the SP-protected application developper is to provide an appropriate error message like "You could not access this service because your institution authentication service did not provide us the required user profile. Please contact the authentication service administrator at your institution.". However it might be a long way from the end user to the IdP admin.
We first thought we would facilitate this through a web page/form on our federation web site. Whenever such issues happen, the SP-protected applications would be responsible for sending the end user to this page. The goal of this page, given an IdP entityID, to look for the contacts for the IdP in the metadata. If the user hits the "submit" button an appropriate error message could be sent to the IdP admins.
I then thought that the form could be implemented in the Shibboleth SP because the SP is already capable of parsing metadata + it knows its own entityID + it knows the IdP entityID.
So the feature request would be to add a contextual error page that would be assist the end-user to send a notification to the IdP admins.