Content-Type: text/html

Sounds a lot like Shibboleth works to me and we have that service on campus now.

 

Rick

 

From: Troy D Murray [mailto:[log in to unmask]]
Sent: Wednesday, March 21, 2012 11:13 AM
To: [log in to unmask]
Subject: Re: Feature Request

 

In short, OAuth is an "open protocol to allow secure API authorization in a simple and standard method from desktop and web applications." (http://oauth.net/).

 

OAuth uses the following roles: client (consumer), server (service provider), and resource owner (user).

OAuth uses the following tokens: Request Token (user requesting my app have access to their protected resources) and Access Token (what the user has approved my application to use to ask your server for the users protected resources)

 

The general idea would be that the current Sentinel Support group, or whatever your new name might be under the reorganization, would be server (service provider).  My web or desktop application would be the client (consumer).  The employee accessing my web or desktop application would be the resource owner (user).

 

A use case would work as follows:

  1. I, the client developer, obtained a set of client credentials (client identifier and secret) from Sentinel Support group to work with your OAuth-enabled API.
  2. An employee accesses my application and my application wants or needs access to the employees ZPID and name (I'm not storing them, just need access to them).  These are protected resources that you, the server (service provider), have stored, but I don't have access to.  
  3. My application at this point requests temporary credentials (aka Request Token) from your server which are provided.
  4. Now my application now sends the user along to your MSU Net login screen. Included in this redirection is the temporary credentials that you provided my application in the previous step along, where to send the user back to my application after you're finished with them, and my client identifier.
  5. The user is prompted to login to your service to authenticate their credentials.  This allows the user to keep their username and password private, I and my application never need them.
  6. After your system successfully authenticates the users credentials, it then prompts the user to "allow" or "deny" my application access (which is requesting access) to their name and ZPID (protected resources being granted access to).
  7. If the user approves, your server then marks the temporary credentials (aka Request Token) as resource owner (user) authorized by the user
  8. The user is then redirected back to my application using the location I told you about when I forwarded the user to you and the approved temporary credentials identifier (aka Request Token).
  9. My application then exchanges the temporary credentials (aka Request Token) with your server (service provider) for an Access Token.  I store then token.  This Access Token is then used by my application to request and access the resource owner (user) protected resources that you have (name and ZPID).

 

Future use of my application by the user wouldn't need to go through all of the Request Token steps listed above, only that the user would login (using your MSU login page) and then my application would use the previously granted Access Token.

 

I see the benefits of this type of authentication as being as follows:

  1. I (the developer) and my application NEVER need nor receive the users MSU NetID and password, that's just between your servers and the users.
  2. I store an Access Token only, random characters generated by your server (service provider) specific to the user.  This string is worthless if someone else learns what it is.  They would need my client application credentials (client identifier and secret) to use it.
  3. Your server contains a list of all approved client applications (web/desktop/etc), like my application, that can use MSU OAuth.  
  4. If a client application is deemed no longer approved, on your server the client credentials are marked as invalid and no future requests by that client application will be allowed (master kill switch).
  5. The user could login to your server (service provider), for example something like https://oauth.msu.edu or https://myid.msu.edu, and see all of the client applications that they've approved to access their protected resources and what protected resources each of those applications is accessing.  
  6. User can remove any of the client applications from their list of approved client applications and no further access to their protected resources by that client application would be allowed.
  7. Sentinel Support doesn't need to maintain or support any client software that would be installed on other parties servers (my application server).  The only required software on my application server would be the OAuth library in whatever language I'm using on whatever platform I'm running (see list at http://oauth.net/code/).

 

I hope that explains it well.  Let me know if you have questions.

 


Troy Murray

Michigan State University

College of Medicine

Life Science

1355 Bogue St, B-136D

East Lansing, MI 48824

P: 517-432-2760

F: 517-355-7254

RedHat 5 Certified Technician

RedHat 5 Certified Systems Administrator

HL7 V2.6/2.5 Certified Control Specialist

 

On Mar 20, 2012, at 2:36 PM, Murphy, Patrick wrote:



Only what I read on the web site last night.  It looks like a method of letting others impersonate you.

 

From: Troy D Murray [[log in to unmask]">mailto:[log in to unmask]] 
Sent: Monday, March 19, 2012 6:36 PM
To: Murphy, Patrick
Subject: Re: Feature Request

 

How much do you know about OAuth?


Troy Murray

Michigan State University

College of Medicine

Life Science

1355 Bogue St, B-136D

East Lansing, MI 48824

P: 517-432-2760

F: 517-355-7254

RedHat 5 Certified Technician

RedHat 5 Certified Systems Administrator

HL7 V2.6/2.5 Certified Control Specialist

 

On Mar 19, 2012, at 6:27 PM, Murphy, Patrick wrote:




I had not heard of this until your email.  Is there something in particular you are looking to implement with this specification?

 

From: Troy D Murray [log in to unmask]]">[mailto:[log in to unmask]] 
Sent: Monday, March 19, 2012 5:11 PM
To: AIS Sentinel Support
Subject: Feature Request

 

Has their been any discussion on offering OAuth as an option that could be administered by users through something like myid.msu.edu?


Troy Murray

Michigan State University

College of Medicine

Life Science

1355 Bogue St, B-136D

East Lansing, MI 48824

P: 517-432-2760

F: 517-355-7254

RedHat 5 Certified Technician

RedHat 5 Certified Systems Administrator

HL7 V2.6/2.5 Certified Control Specialist