Content-Type: text/html

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 [mailto:<a href="/cgi-bin/wa?LOGON=A3%3Dind1203%26L%3DWEBDEVCAFE%26E%3D7bit%26P%3D1332495%26B%3D------%253D_NextPart_000_00BA_01CD077F.EA0A5880%26T%3Dtext%252Fplain%3B%2520charset%3Dus-ascii" >[log in to unmask]</a>] 
Sent: Wednesday, March 21, 2012 3:54 PM
To: 'Jim Green'; <a href="/cgi-bin/wa?LOGON=A3%3Dind1203%26L%3DWEBDEVCAFE%26E%3D7bit%26P%3D1332495%26B%3D------%253D_NextPart_000_00BA_01CD077F.EA0A5880%26T%3Dtext%252Fplain%3B%2520charset%3Dus-ascii" >[log in to unmask]</a>
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 [mailto:<a href="/cgi-bin/wa?LOGON=A3%3Dind1203%26L%3DWEBDEVCAFE%26E%3D7bit%26P%3D1332495%26B%3D------%253D_NextPart_000_00BA_01CD077F.EA0A5880%26T%3Dtext%252Fplain%3B%2520charset%3Dus-ascii" >[log in to unmask]</a>] 
Sent: Wednesday, March 21, 2012 3:42 PM
To: <a href="/cgi-bin/wa?LOGON=A3%3Dind1203%26L%3DWEBDEVCAFE%26E%3D7bit%26P%3D1332495%26B%3D------%253D_NextPart_000_00BA_01CD077F.EA0A5880%26T%3Dtext%252Fplain%3B%2520charset%3Dus-ascii" >[log in to unmask]</a>
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 [mailto:<a href="/cgi-bin/wa?LOGON=A3%3Dind1203%26L%3DWEBDEVCAFE%26E%3D7bit%26P%3D1332495%26B%3D------%253D_NextPart_000_00BA_01CD077F.EA0A5880%26T%3Dtext%252Fplain%3B%2520charset%3Dus-ascii" >[log in to unmask]</a>] 
Sent: Wednesday, March 21, 2012 2:10 PM
To: Troy D Murray
Cc: AIS Sentinel Support; <a href="/cgi-bin/wa?LOGON=A3%3Dind1203%26L%3DWEBDEVCAFE%26E%3D7bit%26P%3D1332495%26B%3D------%253D_NextPart_000_00BA_01CD077F.EA0A5880%26T%3Dtext%252Fplain%3B%2520charset%3Dus-ascii" >[log in to unmask]</a>; Fowlks, Kevin;
<a href="/cgi-bin/wa?LOGON=A3%3Dind1203%26L%3DWEBDEVCAFE%26E%3D7bit%26P%3D1332495%26B%3D------%253D_NextPart_000_00BA_01CD077F.EA0A5880%26T%3Dtext%252Fplain%3B%2520charset%3Dus-ascii" >[log in to unmask]</a>; 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.

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.

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

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

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

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.

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.  

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.

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.

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.

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

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 [mailto:<a href="/cgi-bin/wa?LOGON=A3%3Dind1203%26L%3DWEBDEVCAFE%26E%3D7bit%26P%3D1332495%26B%3D------%253D_NextPart_000_00BA_01CD077F.EA0A5880%26T%3Dtext%252Fplain%3B%2520charset%3Dus-ascii" >[log in to unmask]</a>] 
Sent: Wednesday, March 21, 2012 11:13 AM
To: Murphy, Patrick
Cc: AIS Sentinel Support; <a href="/cgi-bin/wa?LOGON=A3%3Dind1203%26L%3DWEBDEVCAFE%26E%3D7bit%26P%3D1332495%26B%3D------%253D_NextPart_000_00BA_01CD077F.EA0A5880%26T%3Dtext%252Fplain%3B%2520charset%3Dus-ascii" >[log in to unmask]</a>
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

E:  <mailto:<a href="/cgi-bin/wa?LOGON=A3%3Dind1203%26L%3DWEBDEVCAFE%26E%3D7bit%26P%3D1332495%26B%3D------%253D_NextPart_000_00BA_01CD077F.EA0A5880%26T%3Dtext%252Fplain%3B%2520charset%3Dus-ascii" >[log in to unmask]</a>> <a href="/cgi-bin/wa?LOGON=A3%3Dind1203%26L%3DWEBDEVCAFE%26E%3D7bit%26P%3D1332495%26B%3D------%253D_NextPart_000_00BA_01CD077F.EA0A5880%26T%3Dtext%252Fplain%3B%2520charset%3Dus-ascii" >[log in to unmask]</a>

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 [mailto:<a href="/cgi-bin/wa?LOGON=A3%3Dind1203%26L%3DWEBDEVCAFE%26E%3D7bit%26P%3D1332495%26B%3D------%253D_NextPart_000_00BA_01CD077F.EA0A5880%26T%3Dtext%252Fplain%3B%2520charset%3Dus-ascii" >[log in to unmask]</a>] 
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

E:  <mailto:<a href="/cgi-bin/wa?LOGON=A3%3Dind1203%26L%3DWEBDEVCAFE%26E%3D7bit%26P%3D1332495%26B%3D------%253D_NextPart_000_00BA_01CD077F.EA0A5880%26T%3Dtext%252Fplain%3B%2520charset%3Dus-ascii" >[log in to unmask]</a>> <a href="/cgi-bin/wa?LOGON=A3%3Dind1203%26L%3DWEBDEVCAFE%26E%3D7bit%26P%3D1332495%26B%3D------%253D_NextPart_000_00BA_01CD077F.EA0A5880%26T%3Dtext%252Fplain%3B%2520charset%3Dus-ascii" >[log in to unmask]</a>

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 [mailto:<a href="/cgi-bin/wa?LOGON=A3%3Dind1203%26L%3DWEBDEVCAFE%26E%3D7bit%26P%3D1332495%26B%3D------%253D_NextPart_000_00BA_01CD077F.EA0A5880%26T%3Dtext%252Fplain%3B%2520charset%3Dus-ascii" >[log in to unmask]</a>] 
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
<http://myid.msu.edu/> ?


Troy Murray

Michigan State University

College of Medicine

Life Science

1355 Bogue St, B-136D

East Lansing, MI 48824

E:  <mailto:<a href="/cgi-bin/wa?LOGON=A3%3Dind1203%26L%3DWEBDEVCAFE%26E%3D7bit%26P%3D1332495%26B%3D------%253D_NextPart_000_00BA_01CD077F.EA0A5880%26T%3Dtext%252Fplain%3B%2520charset%3Dus-ascii" >[log in to unmask]</a>> <a href="/cgi-bin/wa?LOGON=A3%3Dind1203%26L%3DWEBDEVCAFE%26E%3D7bit%26P%3D1332495%26B%3D------%253D_NextPart_000_00BA_01CD077F.EA0A5880%26T%3Dtext%252Fplain%3B%2520charset%3Dus-ascii" >[log in to unmask]</a>

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