Shibboleth Developers

[Von Welch <>]

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 -------
 >