Support for attribute requirements in the SP

Basics

Technical

Logistics

Basics

Technical

Logistics

Description

Evaluating attribute requirements for applications is something most applications have to do and it would be great to be able to delegate it to the SP.

Here is how I think about how this would work: The SP (either in shibboleth2.xml and/or in web server configuration directives) lists required and optional attributes (future versions could support more complex models based on xacml). Before passing the request up to the application the SP would check that the required attributes are available. If they are not available then the SP displays a message (based on a template) showing the missing attributes. The SP admin can then modify this template to include information about how the user/idp admin should go about fixing the problem.

Finally the SP should include attribute requirements in Metadata and this is the only reason for including the optional attributes which should probably not be checked by the SP.

Environment

None

Linked issues

is related to

SSPCPP-339

Extraction of contacts and other built-in metadata information

Activity

Show:

Scott Cantor February 14, 2012 at 6:58 PM

Closing with documentation written.

Scott Cantor February 8, 2012 at 4:54 PM

http://svn.shibboleth.net/view/cpp-sp?rev=3573&view=rev
http://svn.shibboleth.net/view/cpp-sp?rev=3574&view=rev

Hook mechanism for post-session processing implemented along with a handler to enforce presence of attributes via simple list or full XML AccessControl syntax (overkill).

Machinery added to example config file:

sessionHook and metadataAttributePrefix to App defaults
Metadata attribute extractor for support info
AttributeChecker handler checking for eppn

Scott Cantor September 9, 2011 at 3:55 AM

Hijacking this issue to cover feature additions in the area of "validation" of IdP sessions for use by an application, with associated error handling. We need to dump the "boarding" idea and move to a model where any trusted IdP can be selected, and we deal with attribute release after the fact.

I don't think we should try and link this to the metadata problem. It's much simpler to express requirements in their "processed" form, i.e. I want a header named "foo" and I don't care how many different SAML attributes might end up satisfying foo. That's going to be hours and hours less work, and much easier for deployers.

Scott Cantor October 11, 2010 at 4:10 PM

This issue needs more thought than I can give it for 2.4, but the metadata generator is able to pull in some attribute requirement XML and the attribute-map can include flags marking attributes required or requested and use that to add to the metadata. For SAML2-only deploys, some of this should be useful.