Content-Type: text/html

While it is true that it ought to be up to the developers who should get into a particular service, that is NOT the way the implementation of the MSU Community ID was done. Prior to the Community ID implementation it was 100% safe to assume that only MSU Faculty/Staff and Students—or pretty darn close to just that---could get past a Sentinel sign-in as “Authenticated Users” so applications did not have to check the type. However, rather than setting the acceptable groups restrictions to just the prior set that used to make up “Authenticated Users”, MSU Sentinel Staff simply ADDED the Community ID people into that Authenticated Users group. So, if you have an application (and we have several) that assumes that getting past the Sentinel sign-in means you are “MSU” but you DO NOT want to include “Community ID” users, i.e., anyone who signs up, in that group you need to get the Sentinel people to switch your restrictions away from “Authenticated Users” and into groups that are more MSU identified. We picked PIDXref Student Group which includes all students for the past two and future two semesters and PIDXref Employee Group which includes all current faculty/staff plus retirees. That cut out all the Community ID users and only a few other users. If you have systems that use Sentinel authentication and you only want MSU Faculty/Staff and Students it would be wise to test creating and using a community id to access your system to see if the restrictions you expect are still in place. Like ours, they might not be without taking some action to get the Group settings changed.

 

James

James White, Web Coordinator
International Studies & Programs

Michigan State University

International Center

427 N. Shaw Lane, Rm 207

East Lansing, MI, 48824

(517) 884-2142

[log in to unmask]

 

From: Jim Green [mailto:[log in to unmask]]
Sent: Wednesday, March 21, 2012 4:30 PM
To: [log in to unmask]
Subject: Re: Feature Request

 

The decision of who can sign into a particular service, and with what credential, would rest, as always, with the owners of the service.  We have use cases where service owners want to support authentication via a low-level-of-assurance credential.  That’s why we created CommunityID.  In a way, supporting OAuth would be just another flavor of that.  I should clarify that just because Sentinel supports authentication via CommunityIDs does not mean that users with CommunityIDs can get access to all systems that use Sentinel.  Just the particular ones who want to let them in.  It is not a closed system, anyone can self-provision a CommunityID and those systems that want to can use either Shibboleth or Sentinel to authenticate CommunityIDs, now.

 

 

From: Paduch, John [[log in to unmask]">mailto:[log in to unmask]du]
Sent: Wednesday, March 21, 2012 3:54 PM
To: 'Jim Green'; [log in to unmask]">WEBDEVCA[log in to unmask]
Subject: RE: Feature Request

 

So you think people should be able to use a Google or Yahoo ID to sign into secure services at MSU? Where sensitive university information is involved?

 

Something tells me the University would be against that. There are reasons why the University has its own closed system for authentication, one of them being that these applications have financial and proprietary information accessible through them. You can’t use a generic system that is outside the University’s control for something like that.

 

-J

 

 

From: Jim Green [[log in to unmask]">mailto:[log in to unmask]]
Sent: Wednesday, March 21, 2012 3:42 PM
To: [log in to unmask]">[log in to unmask]DU
Subject: Re: Feature Request

 

I’ve had support of OAuth and/or OpenID on my list of potential things to implement for a couple of years now.  What I think the advantage of OAuth is for users, is the ability to self-provision and self-manage a credential from an OAuth identity provider such as Google or Yahoo, that is widely accepted.  At MSU, we have the CommunityID system, but wouldn’t it be nice for users if they could just use their Google ID instead of having to set up a Community ID with its own password and security question.  In my imagination, an OAuth credential would be just another authenticator besides MSU netid and CommunityID that could work with Shibboleth/Sentinel.  I do have to say my research so far suggests that doing that would be far from trivial, but I did attend a demo and Internet2 last year where Carnegie-Mellon had shoehorned OAuth support into Shibboleth by means of a homegrown OAuth-to-SAML gateway.  It was pretty ugly, but it did work.  Their use case was parents’ access to some student information.

 

From: Murphy, Patrick [[log in to unmask]">mailto:[log in to unmask]u]
Sent: Wednesday, March 21, 2012 2:10 PM
To: Troy D Murray
Cc: AIS Sentinel Support; [log in to unmask]">[log in to unmask]; Fowlks, Kevin; [log in to unmask]">[log in to unmask]; Pal, Sat
Subject: RE: Feature Request

 

From what you have written, this is basically what Sentinel is.  See my responses in green below:

 

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.

The application can receive the MSU NetID as part of the identity of the authenticated user, but never has possession of the password.

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

The application gets an access token from Sentinel today in order to retrieve the users identity credential and prove that the authentication succeeded.

  1. Your server contains a list of all approved client applications (web/desktop/etc), like my application, that can use MSU OAuth.  

Client applications are created by contacting ITS security services.  Sentinel also has an generic MSU Net application defined that can be used without registration, but will only provide the MSU NetID of the authenticated user.  Any other identity information or customization of the login screen require the application to be registered and authorized to the identity fields needed.

  1. 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).

Access to the authenticate to the application is controlled via the Sentinel security application.  Security administrators can “kill” an application at any time which will prevent further logins from being processed.

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

This is one feature that Sentinel does not currently provide.  Security administrators can get a report of the users authorized to the application(s).  They can also see what identity and/or security elements/roles that the user is authorized to within the application.  If this is something that a user would want to see for themselves, then we would have to extend the security administration application to support that.  But again, access to applications is centrally granted, not authorized by the individual user.

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

Sentinel was written with centralized security in mind.  Basically, HR needs to authorize you to access SAP.  You cannot just give yourself access to SAP.  Likewise, SAP requires certain pieces of information to identify you.  You cannot withhold the required information from the application and expect it to work.

I see the user authorizes model would be better suited for signing up for things like Facebook where you can choose to use the service or not.  But, for University applications, you need to be granted access to the applications you will need to perform you job.  I don’t see letting a user opt out of required applications as s needed feature.

  1. 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/).

The OAuth library is in essence the Sentinel Client in this scenario.  A specialized OAuth library would need to be present for each application server type supported.  This is no different than the Sentinel model.

 

 

 

The only changes are to some of the terms, and that access to the identity fields is not granted by the user, but by campus central administration. 

 

From: Troy D Murray [[log in to unmask]">mailto:[log in to unmask]]
Sent: Wednesday, March 21, 2012 11:13 AM
To: Murphy, Patrick
Cc: AIS Sentinel Support; [log in to unmask]">[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