Shibboleth Developers

["David L. Wasley" <>]

Yes - mapping of identifiers between domains.  Seems to me this 
should be the responsibility of the target domain.  I.e. the 
"service" of using the local (origin) identifier is being provided to 
the target domain and the target domain has the responsibility to 
determine what rights accrue to that identifier.

However, in the Grid VO case I think Von is asking for something 
different.  As I understand it, the Grid will issue its own 
credentials (x.509 certs) and then wants to use its own identifier to 
access information about a subject "known" in another domain - 
without using any identifier native to that domain.  (In fact it 
isn't clear even how the Grid app would know where that domain is 
found!)

In a generic case, if a VO didn't want to run any Auth* 
infrastructure but merely rely on "borrowed" AuthN and AuthZ 
information from a variety of member home orgs (HOs), then I would 
suggest that the VO use HO EPPNs to identify its members and rely on 
HO AuthN and HO AAs to verify users and provide information about 
them.  The VO could, as one of its services, provide an internal 
database that would hold additional information about its members 
and/or provide mapping to other identifiers but then it verges in 
running infrastructure.

WRT:
At 1:50 PM -0600 1/20/04, Von Welch wrote:
> Leveraging Shib as a piece of AA software. Shib is written,
> standards-based and supported, so why should we duplicate that effort?
> If we can figure out how to make it interoperate with the Grids
> (specifically the Globus Toolkit) then if a VO needs a AA, I can say
> "Run Shib, and configure the Globus Toolkit like so".

A Grid Shib AA can look like a very flexible, powerful front end to a 
Grid-run member database.  Configuring an AA to do this should be 
quite easy.  Grid apps would not need to rely on a Grid-run Shib 
handle server or WAYF or Shire.  The User could offer their Grid 
x.509 cert to the Grid App as a credential and it would contain the 
HO EPPN in the CN.  That identifier would be passed to the Grid AA 
and the App would get back a pointer to the HO AA as well as any 
other useful Grid-known information.  If HO information was needed, 
the App would contact the HO AA.

Alternatively, the User could rely on their HO AuthN and Shib 
infrastructure.  The User would approach the Grid App or a Grid 
"gateway" via a web browser interface, answer the WAYF question, 
authenticate locally, and the Grid App or gateway would then retrieve 
the User's EPPN.  A Grid gateway could then make the User's EPPN 
available to Grid Apps for use against the Grid AA or the User's HO 
AA.

Either way, I believe use of the HO EPPN is the key to making all this work.

        David


-----
At 3:01 PM -0500 on 1/20/04, Scott Cantor wrote:

>  > Therefore, if you want a VO to "borrow" a persistent identifier for
> >  members of a Grid community, you have to use the EPPN known to the
> >  member's HO.  The Grid applications can map that EPPN to a Grid
> >  identity.  Better yet - the Grid member can be known by their HO EPPN
> >  from the git go.  I see no motivation at all to ask every Home Org to
> >  store additional identifiers for use in other domains.
>
> Well, the obvious reason is the one Liberty has, namely to allow the VO to
> function with some relationship to its users independent of their HO or of
> the user changes HO's. That requires a persistent identifier owned/managed
> by the VO, and Liberty (and SAML) aim to link the two.
>
> In Liberty's case, it's a business (I guess a CRM) justification to not let
> the HO "own" the relationship with the "customer". Obviously that driver may
> not apply here.
>
> -- Scott