Shibboleth Developers

[Walter Hoehn <>]

As Scott indicated earlier, an AA can already be configured to answer 
this type of query (give me the attributes for user ""). 
 A current limitation is that each AA can only "understand" one type of 
user identifier at a time.  The SAML attribute request format provides a 
means by which an AA can distinguish among "user identifier formats" and 
the AA software could, without too much trouble, be extended to handle this.

I do agree that the AA is potentially useful outside of the cononical 
shib use case, but the problem with this proposal is that not all 
identifiers are created equal.  Once the use is no longer anonymous, you 
start authenticating directly to the target, and you have no concept of 
presence; why not just use ldap?

-Walter


David L. Wasley wrote:

> Actually, this scenario was anticipated early on but was not central to 
> the initial Shib design.  Clearly the AA can be a generalized 
> "authorization" server speaking with authority about subjects it 
> "knows."  I would love to see this capability added (soon? eventually?).
>
> Questions include:
>
> 1) What protocol?  Clearly it could support (conceptually) anything from 
> "whois" to a fully qualified LDAP query.  In light of SAML/SOAP however, 
> I would encourage a protocol that would support that methodology.
>
> 2) What information can be requested?  Current Shib AA implementation 
> doesn't look at query parameters (as I understand it) but merely 
> responds with whatever it is willing to release to the identified 
> target.  Perhaps a query parameter definition is needed so that a 
> requester could ask, for example, for a PKI certificate associated with 
> an email address, or ask for an email address associated with a public 
> key, or ...
>
> 3) What information might/should be released?  The SHIB AA rules are 
> roughly "release only public information to an unknown requester" and 
> only designated information to a known target.  Hence, any 
> server/"interested party" could send a query to the AA, presumably with 
> some content that would identify a single record in its DB, and the AA 
> would respond appropriately.  The requester would identify itself with a 
> PKI certificate, as it does within Shib.
>
> So, in the case Tom identified, the "resource manager" would open a 
> connection to the AA, submit a query for information about 
> <> that is either unauthenticated or authenticated, and 
> would receive an answer based on the AA's ruleset.
>
> Fertile ground.
>
>     David
>
> -----
> At 12:27 PM -0400 on 9/24/03, Scott Cantor wrote:
>
> >  > Abstracting a bit from the particulars of this use case, it might be
> >
> > >  worth considering a model in which a resource manager can initiate a
> > >  request for attributes about an already-authenticated user.
> > >  Instead of attributes being bound to users by virtue of the 
> > > authentication
> > >  process employed, as occurs in shibboleth v1 because of its focus on 
> > > the
> > >  web browser use case, there would need to be a step in which a resource
> > >  manager asks an origin to search for a user identity based upon 
> > > whatever
> > >  authenitcation artifacts it has in hand 
> > > (
> > >  in Mark's
> > >  example). Attributes could only be transmitted if that search
> > >  is successful.
> >
> >
> > There's nothing all that much precluding it, except that the AA currently
> > doesn't support multiple mappings of subject identifier to principal.
> > Nothing very complex to change, though. But authentication is the real
> > problem. How do I convince mod_dav I'm mewilcox?
> >
> > -- Scott

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature