UC Federated Authorization Framework Discussion
From UGP-Wiki
Participants
David Walker <DHWalker@ucdavis.edu>, (530) 752-9390
Bill Labate <labate@ats.ucla.edu>
Kathleen M Beyer <kmbeyer@ucdavis.edu>
Albert Wu <albertwu@ucla.edu>
Kejian Jin <kjin@ats.ucla.edu>
Prakashan Korambath <ppk@ats.ucla.edu>
Upcoming meeting date February 18th Wednesday, 1:00 PM to 3:00 PM
Proposed Discussion Topic by David Walker:
Here's a proposed set of discussion topics:
* The current (non-UCTrust) authentication architecture for UC
Grid. Anything you can tell the rest of us to read before the
meeting would be appreciated. Also, Arlene mentioned that she
has heard some concerns about the current architecture from Rich
Wolski. Arlene, can you summarize those concerns for the group?
* What we would need to change in that architecture for UCTrust
integration.
* What we would like to change in that architecture while we
integrate into UCTrust (or after integration).
Everyone,
Prakashan and I just talked. We'll be meeting 1:00-3:00 on 2/18 at a location in ATS that Prakashan will announce.
In preparation for our discussion...
* Prakashan and Keijin, please send the rest of us any reading
assignments you think will help the rest of us understand UC
Grid's needs.
* Arlene, please summarize Rich Wolski's concerns.
* To get the discussion rolling, I'll draft my views (suitable for
shredding) on how the UCTrust / UC Grid integration might work.
And now for my action item...
* It's my understanding that the Globus Toolkit uses digital
certificates to identify users.
* It's also my understanding is that UC Grid currently associates
a username (and password) with those certificates. The
username/password pair, not the certificate, is used to access
the UC Grid Portal.
* At a minimum, UCTrust could simply replace the username with an
identifier in a SAML assertion. Everything "downstream" would
be the same.
There are, of course, a number of possible enhancements, probably none
of which are short-term:
* Have the certificate be part of the SAML assertion, implying
that the certificates are managed by the campus identity
management people.
* Have UC Grid use SAML assertions internally, instead of
certificates.
* and on and on...
See you all next week!
We are meeting in room 3909, Math Sciences Bldg. on Wednesday, 2/18/09 between 1:00 PM and 3:00 PM. The URL below will give directions to the Math Sciences building http://www.ats.ucla.edu/location.htm
Please let me know if anyone needs parking slot reservation. A brief description of current UC Grid certiicate creation process is available here. http://www.ucgrid.org/wiki/index.php/Register_Service http://www.ucgrid.org/wiki/index.php/Site_Map Currently, we are using UCLA Shibboleth just to authenticate the users first time when they apply for the grid account. We sign the X509 based certificate and store it in our myproxy server. Each time users come back to login they are asked to input the username and the passwd used to create the certificate. We retrieve the short lived credentials from the myproxy machine to the portal machine. All transactions between the portal and the compute clusters are done using the X509 based credentials. Prakashan
I asked Rich last week if he could give me a synopsis of his current thinking. I haven't heard from him, so he may not be around. Prior, admitedly many months now, discussions revolved around how UC Grid would authenticate in the context of one or more campuses joining other grids - open science, texas open grid, teragrid etc. There was also concern over what the costs (how to execute) might be per campus, in any architecture that was primarily based on an externalized pki security model. I would prefer for him to provide his current thinking though. Teragrid is already in InCommon and I thought texas was doing it too from a conversation I had at Educause, but they don't seem to be listed.
On the first bullet enhancement you mentioned David, is this the typical x.509 deployment in an ldap environment you are thinking of - public key stored in the directory? arlene
Arlene,
Regarding my enhancement bullets, I didn't really think it through in great detail. I suppose I'm thinking of a standard x.509/LDAP environment, but we'd also need a standard encoding of the cert for SAML. I suppose we could just use PEM encoding, if nobody's standardized it yet.
Of course, this is tantamount to creating another PKI project, a third rail in ITLC discussions a few years ago, as you are very well aware. Lightening hasn't stricken me as I'm typing this, though, so maybe we could pull it off now. It certainly would be easier, now that we have UCTrust.
Your comments about the (PKI) trust between UC Grid and other grids, though, make me wonder what the right approach is. Do any of us know how Teragrid, Open Science Grid, et al, are dealing with this?
David
Hi,
Shibbolizing Gridsphere already exists. People had changed the gridsphere so that it allows the shibboleth as a PAM for gridsphere.
That project is from Australia: https://mams.melcoe.mq.edu.au/zope/mams/kb/all/GridSphere%20Wink%20demo.zip/view
I have their source code.
Basically, the shibboleth IdP has to pass userName, surName, givenName, Organization, email, IDP, Role to gridsphere which internally create a User Object for gridsphere at real time. It modified the login of gridsphere by doing that.
I am more insterested to discuss how we could create a short live credential for user that will authorize the user to use certain resources. (authorization) I will really like to tell the meaning of "single-Sign-On". Most people uses that shibbolized gridsphere for portal authentication of portal sign-in, but it is never used for authorization of resources.
I have worked on a project before. That project will create the Unix virtual workspace and create a certificate (once) and generate proxy at real time and submit job and application to the cluster as pool user. please see https://research.ucgrid.org anyone with UCLA ID will be able to have a virtual desktop and submit job, or run some grid applications...
I hope the discuss we planed will help us to generate some ideas about how to do that in a secure way and easy-to-deploy way. There are many ways of doing the same thing, but we really like to have your input:
The following are my thought for doing that:
Method 1: IdP gets the username and password, it used the username and password to retrieve a proxy from myproxy.ucgrid.org. It is just a command something like this: get-myproxy -h myproxy.ucgrid.org username password. it will include that delegated and short live credential in Assertion.
Method 2: IdP passes a unique string (like the one in openldap) to SP, SP understand that and lookup some sort database to figure out the username and password and generate user proxy and use that for job submission.
.......
more input and discussion is needed!
Thank you very much for your time...
Regards,
Kejian Jin
