Shibboleth Developers

[Tom Scavo <>]

On Mon, 28 Mar 2005 08:40:08 -0600, Walter Hoehn 
<>
 wrote:
> Could this be handled more easily if the grid client proxied an
> assertion containing only an authN statement and the grid service used
> this data to construct a direct query to the IdP?

GridShib has four use cases under consideration:

Case 1: Attribute pull w/o anonymity
Case 2: Attribute push w/o anonymity
Case 3: Attribute pull w/ anonymity
Case 4: Attribute push w/ anonymity

Up until now, we have only discussed Case 1 with you (which seems to
be fairly well understood).  We are just beginning to lay the
groundwork for the other use cases.  This thread is our initial foray
into Case 2.

Walter, your brief description above sounds a lot like a normal shib
browser profile with grid client and grid service substituting for
browser and SP, respectively.  We considered this approach, but
dismissed it as a solution to Case 1 for various reasons.  Most
importantly, authentication of the grid client occurs at the grid
service, so it makes sense to start the simplest profile there.

In Cases 3 and 4, it is likely the grid client will visit the IdP
initially---to obtain an anonymous proxy cert, to establish a
(dynamic) mapping between DN and principal, and yes, maybe even to
obtain an authn assertion.  There are lots of issues that arise in
these use cases; however, we see them as the "meat and potatoes" of
GridShib.

Cases 1 and 2 are interim use cases.  In Case 2 (like Case 1), for
simplicity we assume there is a grid mapfile on the IdP.  The AA
refers to this mapfile to map the DN to the principal.  (We will
provide a plugin to do this.)  The difference between Cases 1 and 2 is
that the grid client obtains attributes *before* visiting the grid
service.  In this case, the burden of communicating with the AA shifts
from the grid service to the grid client.

A grid client does not have a providerId and it does not have
associated metadata (like a grid service).  Presumably, if a grid
client asks for attributes about itself, ARP processing is
circumvented.  If a grid client is to formulate a specific attribute
query (to avoid receiving ALL attributes), it will need to know the
attribute requirements of the grid service.  This is the problem we
are wrestling with here.

Scott suggested that the grid client consume the grid service
metadata, which is what I meant when I said the grid client would have
to talk to the grid service initially.  We are trying to avoid this. 
Essentially, what we'd like to do is communicate attribute
requirements to the AA by reference (not by value).  Since the AA
already knows the attribute requirements of the grid service (via
ARP), we were hoping to capitalize on that in some way.  Any ideas?

Tom