Notes from the 2009-02-18 Meeting at UCLA

On Fri, 2009-02-20 at 11:40 -0800, Prakashan Korambath wrote:

Thanks David for the clarifications.

I suppose the two campus IdPs returning two different ePPN's are ok for a user who is member of multiple campuses as long as both entries are mapped to the same user in the client side grid-mapfile (for example).

Yes, although that person may actually want two grid "persona," because of two different jobs for the two campuses, for example.  Either way, there's a way to deal with the issue.

Just to clarify, the "passwd" and the "encryption/decryption key" are the same thing, right?

Yes. That is what I meant.

Thanks.

David Walker wrote:

Prakashan,

I just noticed that I didn't address one of your questions:

Only question I have is that the ePPN returned by IdP will be unique enough to give us a one and only common name (CN) in all of the 10 campuses.

It is unique.  The ePPN has two parts, a local part that the campus keeps unique within its own domain, and a "scope" that identifies the campus.  The scope's uniqueness is guaranteed by InCommon and is based on the campus's domain name.  Put together, the ePPN comes out looking like an electronic mail address; my ePPN is dhwalker@ucdavis.edu.

Note that this scheme does raise the possibility of a single person having two ePPNs from two different campuses.  That's really a user education issue, though, not a security issue.  Those users need to understand that logging in via one campus will not give them them same grid access as logging in via another campus.

David

On Fri, 2009-02-20 at 11:00 -0800, David Walker wrote:
Thanks for sending this, Prakashan.  I've edited some comments below.

On Thu, 2009-02-19 at 11:15 -0800, Korambath, Prakashan wrote:
All,
Attached is a slide that came out of our discussion here at UCLA yesterday with David Walker, Arlene Allen and Albert Wu. Albert runs our UCLA campus Shibboleth service. I am sending out this so that everyone can comment on the workflow. It is a practical workflow in the sense that we can implement it. Some explanation of the slide is below. We can also discuss it during our next UC Grid meeting also.

Identity Provider:  All 10 campuses will have one. If any campus is missing now, they will have it shortly (David and Arlene can comment on that)

Within UCTrust, we're tracking the ten campuses, plus LBNL and UCOP.  We're also tracking membership in InCommon (the national identity federation for higher education) and UCTrust (UC's subset of InCommon that provides a better defined, and higher, level of assurance).  Once a campus is in InCommon, it has an IdP that can interoperate with SPs.  The UCTrust requirements are really on the human processes of managing and verifying identities, as well as defining a few additional attributes.

At this time, all of these locations are members of InCommon except UCSB.  Of the eleven locations in InCommon, only LBNL has not certified to UCTrust's higher level of assurance.  The five medical centers are included with their campuses.  In the past, we've discussed the issue of the level of assurance and decided that UC Grid would not require UCTrust's higher level of assurance, so (assuming we still believe that), eleven of UC's locations are ready to go.  There's a status chart on the UCTrust wiki at https://spaces.ais.ucla.edu//x/UYC3.

Service Provider:  Example our Campus Grid Portals

In the current scheme Service provider will first re-direct the user who are trying to use the service to Identity provider and the identity provider in turn will return an ePPN token.  The ePPN token will have enough information for us to sign a unique X-509 certificate except the passwd (encryption key).  This encyrption/decryption key will be randomly generated by the web-service workflow on the Certificate signing machine.  The certificate signing machine will store the passwd in a database with encryption.   Once the certificate is signed a proxy with certain life time will be pushed to myproxy server.  After this step, a short lived credential will be returned to the Service provider where the user tried to login (avail the service). 

Just to clarify, the "passwd" and the "encryption/decryption key" are the same thing, right?

For all subsequent login attempts (on Service provider) by the user the certificate signing step is by-passed and only the short lived credential retrieval will be happening.  The ePPN provided by the campus identity server will be used to authenticate the users and is used in one of the two components (username) in the X509 certificate creation procedure. 

I would have worded the last sentence a little differently:  "The ePPN provided by the campus identity server will be used to identify the users and retrieve their certificates and passwds."

David, Albert, Arlene or Kejian may please comment on it if my interpretation deviates from what we discussed.  Only question I have is that the ePPN returned by IdP will be unique enough to give us a one and only common name (CN) in all of the 10 campuses.  I suppose that is the case. Thanks.

To summarize what all this means for the process of gaining access to UC Grid resources:

• Anyone with a valid UCTrust login can become a user of UC Grid's default pool simply by browsing to the UC Grid portal.  [There is a policy issue here that should probably be resolved by the ITLC.  I would suggest that we modify this statement to say, "Anyone member of a UC campus community can use their UCTrust login to become a user of UC Grid's default pool simply by browsing to the UC Grid portal."  This will require the UC Grid portal to check the affiliation attribute in the SAML assertion before proceeding with the registration process you've described, as many campuses provide logins to partners that are not "members" of the campus community.]

• To become a cluster user, a person would contact the cluster administrator after becoming a default pool user, providing their ePPN.  This will obviate the need for temporary assignment (and potential de-assignment) of grid identifiers, as described on the UC Grid wiki athttp://www.ucgrid.org/wiki/index.php/Workflow.
• To become a user of a pool other than the default pool, the process will remain the same as for clusters for now, substituting "pool administrator for "cluster administrator."  However, we need to research what communities those pools may serve, what other services might be needed by those same communities, and how UCTrust could be extended to help identify the members of those communities.  We discussed virtual organizations and, more specifically COManage (http://middleware.internet2.edu/co/), as potentially useful models.

A few other things:

• When we talk about authorizing users for anything other than the default pool, we talking about what resources will be presented to the user by the portal.  The real authorization to use a cluster or a non-default pool is controlled by the cluster or pool administrator, not the grid.
• We discussed the desirability of having the IdPs issue certs, rather than the grid, and to be able to assert them via SAML and Shibboleth.  This is an attractive idea, but there isn't a lot of interoperability among the certificates used by various applications, so it's not clear that UC Grid usable certs could be reused, for example, by an electronic mail client for S/MIME message signing and encryption.  The consensus was that this probably isn't worth pursuing at this time.
• We've collected some materials from our discussion prior to the meeting on the UCTrust wiki space at https://spaces.ais.ucla.edu//x/SA43AQ. I'll add this note, too.
• I'll foward this to the UCTrust Work Group for their comments, too.

David

Prakashan