Shibboleth Developers

["Von Welch" <>]

Scott,

 Thanks. I'm talking at the implementation level as opposed to
architectural, so I understand that some of my statements are less
abstract that they could be.

 I think I get it now, I'll update the profile and put out another
verison.

Von


Scott Cantor writes (14:16 January 20, 2005):
 > > As I understand what you are suggesting, an IdP id would be placed in
 > > the extension; that IdP would resolved by the service through the Shib
 > > Metadata API (which uses a proprietary metadata file distributed by
 > > some OOB method) to a set of one or more URLs to AAs associated with
 > > that IdP.
 > 
 > Well,
 > 
 > - we're moving to the use of standard SAML metadata and would encourage 
 > your
 > deployment to do the same
 > 
 > - you don't *have* to use the existing Shibboleth metadata subsystem to do
 > this work, we're just saying "use metadata to indirect the process", and if
 > you want to use our code or develop alternative plugins, you're welcome to
 > 
 > - the Shibboleth API knows nothing about files or anything else, it's an
 > abstract interface to the information, you can supply the data in whatever
 > format/mechanism you like
 > 
 > - the API is designed as a thin wrapper around the SAML metadata schema by
 > design, but it can certainly evolve or be subclassed to do other things or
 > support community extensions, which I'm in fact doing for Shibboleth so as
 > to avoid polluting the core API which will eventually be in OpenSAML
 > 
 > > As Tom mentioned the intent is to allow the service to authentication
 > > of the AA to the service.
 > 
 > I think this is sufficiently generic without saying "must use or have a
 > certificate" unless you want to constrain things to that degree. It's up to
 > you.
 > 
 > Shibboleth doesn't require use of PKI or SSL to do authentication of the
 > SOAP, we just happen to use that.
 > 
 > > Is the suggestion here that the identity of the AA is available
 > > through this interface?
 > 
 > The metadata API supports accessing information about the keys usable by a
 > given system entity. This could be implemented in many ways.
 > 
 > We then separate out the actual trust processing in the case where the
 > metadata doesn't supply an actual key. It might say "AA foo can use key 
 > bar"
 > and then the trust API answers the question "is this certificate usable" by
 > comparing it to that information, perhaps with path validation, etc.
 > 
 > -- Scott