[prev in list] [next in list] [prev in thread] [next in thread] 

List:       shibboleth-dev
Subject:    Re: [Shib-Dev] Shibboleth IdP OpenID Extension
From:       Will Norris <will () willnorris ! com>
Date:       2009-12-17 23:21:50
Message-ID: E46DAD46-0A6B-4578-8679-3996F2274693 () willnorris ! com
[Download RAW message or body]

inline...

On Dec 17, 2009, at 3:04 PM, Peter Williams wrote:

> Out of interest:
> 
> Can the metadata be signed (and will Shib verify the sigs using its usual \
> conventions for key management)?

It is using the same metadata engine for this as all other SAML metadata, so signing \
and caching is handled the same.


> https://spaces.internet2.edu/display/SHIB2/OpenIDMetadataProfile
> 
> if I add an RP extension, will Shib largely ignore what it doesn't recognize.
> 
> The obvious thing to do is put an RP's host-meta in an extension of \
> SPSSODescriptor, whose implied subject is the descriptor's SAML entityid. Its as \
> good a mechanism as any for indicating the URL namespaces that the listed ACS \
> endpoints can speak for.

The intention is not to use SAML metadata for host-meta documents, though that may be \
worth giving thought to down the road.  Right now, the metadata is simply a means for \
whitelisting OpenID relying parties.


> Can it support SAML-style handling of multiple ACS, with either indexed or explicit \
> URLs?

The extension does not presently make use of ACS's, but will be doing so in a similar \
manner as XRDS-based return_to validation.  That is, whatever return_to is specified \
in the Auth request will be used so long as it matches the realm, and has a matching \
ACS for that relying party.  ACS indexes are not used... if an Auth request does not \
specify a return_to, per the OpenID 2.0 spec, there is no return message.


> Does the IDP enforce SAML style cache management (governing the validity of the \
> SPSSODescriptor)? 
> I.e. by design, will the OP stop working with an RP once its (cached) metadata is \
> out of date, even though it was logically white-listed?

see above regarding signing (all the same rules apply as with standard metadata).

-will


[prev in list] [next in list] [prev in thread] [next in thread]