Shibboleth Developers

["David L. Wasley" <>]

Von, Thanks, that helps but it still leaves me uneasy.  While I think the 
problem of "who is authoritative for what" can be solved with signed 
assertions ("IEEE asserts that 

 is a member in good standing") stored in local AA's database, there are 
still the problems of maintenance (how often is the stored assertion 
refreshed or verified?), scalability (how many of these assertions can one AA 
maintain, and for what purposes?) and privacy (do you want one AA to know 
everything about you?).  That's why I suggested another way to look at it: 
use the local campus identity to apply for membership or privileges and then 
rely on an appropriate organizational identity to make use of those services. 
("identity" == "EPPN" + "attributes")

Clearly the downside of this model occurs when a person is working across 
security domains, e.g. using the campus library and the IEEE library 
interchangeably -- you'd like to make this seamless to the user by avoiding 
the dual WAYF problem.

In the case of the GRID, with a "virtual organization" managing resources 
albeit located at multiple institutions, it isn't clear that there is a lot 
of overlap.  I would argue that a VO is still an O and has rules and 
management and decision making processes, etc.  It is that O that decides who 
is "in" and what they can do.  It seems sensible therefore that it run the 
AuthZ support service (but it clearly does not need to run the AuthN 
service). 

A counter example might be a GRID user who wants to use resources, e.g. 
machines or datasets, that are not controlled by the GRID VO but are to be 
used in conjunction with GRID resources.  Now you have a multi-domain AuthZ 
problem.  Here I think proxy or "delegation" certs might work: "EPPN 

 hereby delegates eligibility to supercomputer ANL23 to use his/her privilege 
to gain access to dataset UMich 12234 for the next 48 hours."  Or something 
of the sort.  If the UMich domain can verify the cert (and accept the 
assertion) then it should be willing to grant access as if the User was 
directly asking.  It might even ask the UMich AA for attributes to confirm 
the user's eligibility.

What am I missing?

Thanks,
        David
-----
At 2:54 PM -0600 on 1/12/04, Von Welch wrote:

>David,
>
> The bigger picture is that the user is a member of one or more
>virtual organizations (e.g. a multi-organizational scientific
>experiment like GriPhyN, iVGDL, etc.). The virtual organization is
>then either running Shib services themselves or they have agreements
>in place with local domains of their users that allow them to be
>authoritative for some attribute space that is served using shib
>servers at those domains. (This is akin to the IEEE use case model as
>I understand it, where IEEE says who is a member but the campuses
>actually issue assertions to such.)
>
> The assertions are then of the form "User is member of VO", "User is
>a {PI, developer, analyst} in VO", etc. And these attributes could be
>used by services to give access based on these attributes (e.g. "Any
>member of GriPhyN may read files from this service").
>
>HTH,
>
>Von
>
>David L. Wasley writes (12:32 January 12, 2004):
> > I'm sorry to come into this so late (and maybe I'm sorry I'm asking
> > this now ;-)
> >
> > What is the reason, in the GRID context, for asking for attributes?
> > I ask this because I think the scenarios described below are
> > problematic, depending on what is intended.  Is it:
> >     (a) is this the person who applied for use of this GRID resource?
> > or
> >     (b) what GRID resources is this person eligible to use?
> > or
> >     (c) something else?
> >
> > I can see a case for asking a local (campus) domain to verify that
> > the person is the same one who applied to use the GRID but I wouldn't
> > rely on the local domain to say anything at all about what the person
> > is eligible to use.  I can also see a very good reason for GRID sites
> > to implement shibboleth among themselves with a "local" domain being
> > the GRID central clearing house and targets being the various
> > resources around the world.
> >
> > In the latter case, a researcher might use their campus Shib domain
> > to supply an EPPN when applying for GRID use and then use this EPPN
> > to authenticate to the GRID central clearing house.  Once "inside"
> > the GRID domain, the user would be able to request use of resources
> > (targets) and those targets would ask the GRID clearing house AA to
> > provide information about what the researcher can use, etc.
> >
> >     David
> > -----
> > At 2:05 PM -0600 on 1/12/04, Von Welch wrote:
> >
> > >------- start of forwarded message -------
> > >From: "Von Welch" 
> > ><>
> > >To: 
> > >
> > >Subject: More detailed Grid scenarios
> > >Date: Mon, 22 Dec 2003 13:18:32 -0600
> > >
> > >
> > >Below, in greater detail, are three possible ways I could see Shib
> > >integrated into a basic Grid use case. All three use a basic model of
> > >the user authenticating to a target service and then the target
> > >service contacting a Shib AA for attributes it uses for authz.
> > >
> > >The differences in the cases are:
> > >#1: No session or privacy, user subject name is only identifier
> > >#2: No privacy, but handle is used to establish a session
> > >#3: Handle used for session, sort-term X.509 credentials used for
> > >     privacy.
> > >
> > >Basically, the level of feature support increases from scenario #1 to
> > >#3 as does the level of complexity.
> > >
> > >I think the question to be answered here is "Is there a particular
> > >level that makes the most sense or can this just be made a
> > >deployment-time decision?"
> > >
> > >Von
> > >
> > >--------------------
> > >
> > >A note on Delegation: My assumption is that the user is doing full
> > >delegation of rights to any process running on their behalf. Any such
> > >process is given a proxy certificate (bound to new private key) by the
> > >user. (This can be repeated, a process can delegate to another process
> > >by issuing a proxy certificate from its proxy certificate, etc.)
> > >
> > >--------------------
> > >
> > >Alternative #1: Credential Pull Model, No Privacy
> > >
> > >In this model, there is no session concept.
> > >
> > >* User (or process running on the user's behalf with delegated
> > >credentials from the user) authenticates to target service with normal
> > >Grid credentials (EEC or Proxy Certificate and associated private
> > >key). Through this authentication the target service established the
> > >subject name of the user.
> > >
> > >* Target service consults local configuration which maps the subject
> > >name of the user to a particular Shib attribute authority (AA). (This
> > >mapping is probably done on wildcards using components of the subject
> > >name, but could also be done via pointer contained in non-critical
> > >extension in user's certificate.)
> > >
> > >* (Getting into details of how Shib AA works that I don't know, so
> > >making guesses here...) Target service contacts the AA over a SSL
> > >protected channel. Local, trusted copy of certificate of Shib AA is
> > >used to verify that the correct AA is being communicated with. Target
> > >service performs mutual authentication with shib AA using it's own
> > >certificate & private key.
> > >
> > >* Target service presents user subject name and requests attributes
> > >for user.
> > >
> > >* Shib AA consults ARPs to determine target service's right to access
> > >attributes for user. Delivers list of attributes to target service
> > >over SSL-encrypted link (don't see any need for signing of
> > >attributes).
> > >
> > >* Target service uses attributes along with local policy to make
> > >access control decisions..
> > >
> > >--------------------
> > >
> > >Alternative #2: Session based model with Handle as WAYF, No Privacy
> > >
> > >* User (or process running on the user's behalf with delegated
> > >credentials from the user) authenticates to a local authority. This
> > >authority establishes a handle for the user which is entered into Shib
> > >AA configuration as a handle normally would.
> > >
> > >* Handle is placed into signed authn assertion along with user's
> > >subject name. Lifetime of handle and authn assertion is set equal to
> > >lifetime of user's credentials (probably with some administratively
> > >set maximum). Authn assertion is returned to user.
> > >
> > >* User generates new proxy certificate from current credentials,
> > >including the authn assertion as a non-critical X.509 extension. (This
> > >step is really a hack to keep from having to deal with the authn
> > >assertion as a separate hunk of bits in terms of credential management
> > >and in the protocol).
> > >
> > >* User authenticates to target service with proxy certificate chain
> > >containing authn assertion.
> > >
> > >* Target service scans certificate chain used by user to authenticate
> > >and finds authn assertion. (Authenticate of user's possession of
> > >private key during tells target service user owns authn assertion
> > >embedded in chain.)
> > >
> > >* Target service checks subject name in authn assertion to verify
> > >user's ownership of authn assertion and verify user's right to assert
> > >handle.
> > >
> > >* Target service checks signature on authn assertion with local copy
> > >of aa's certificate to verify integrity of assertion.
> > >
> > >* Target service determines the appropriate AA for the user. (Probably
> > >something in authn assertion.)
> > >
> > >* Target service contacts the Shib AA over a SSL protected
> > >channel. Local, trusted copy of certificate of Shib AA is used to
> > >verify that the correct AA is being communicated with. Target service
> > >performs mutual authentication with shib AA using it's own certificate
> > >& private key.
> > >
> > >* Target service presents handle and requests attributes for user.
> > >
> > >* Shib AA consults ARPs to determine target service's right to access
> > >attributes for handle/user. Deliverslist of attributes to target
> > >service over SSL-encrypted link (don't see any need for signing of
> > >attributes).
> > >
> > >* Target service uses attributes along with local policy to make
> > >access control decisions.
> > >
> > >
> > >--------------------
> > >
> > >Alternative #3: Temporary credential model with privacy
> > >
> > >* User (or process running on the user's behalf with delegated
> > >credentials from the user) authenticates to a local authority. This
> > >authority establishes a handle for the user which is entered into Shib
> > >AA configuration as a handle normally would.
> > >
> > >* Local authority creates new short-term proxy certificate for user
> > >with handle as subject name (or more likely encoded as part of subject
> > >name - e.g. as common name). Proxy certificate contains a non-critical
> > >X.509 extension with pointer to AA. Proxy certificate is delegated to 
> > >user.
> > >
> > >* User authenticates to target service with proxy certificate from
> > >local authority.
> > >
> > >* Target service determines the appropriate AA for the user from
> > >extension in proxy certificate.
> > >
> > >* Target service contacts the Shib AA over a SSL protected
> > >channel. Local, trusted copy of certificate of Shib AA is used to
> > >verify that the correct AA is being communicated with. Target service
> > >performs mutual authentication with shib AA using it's own certificate
> > >& private key.
> > >
> > >* Target service presents handle/subject name for user and requests
> > >attributes for user.
> > >
> > >* Shib AA consults ARPs to determine target service's right to access
> > >attributes for handle/user. Delivers list of attributes to target
> > >service over SSL-encrypted link (don't see any need for signing of
> > >attributes).
> > >
> > >* Target service uses attributes along with local policy to make
> > >access control decisions.
> > >
> > >
> > >
> > >------- end of forwarded message -------
> >