I see the benefit of OpenID being accept is for something like NCRS
(Non-Credit Registration System). For non-MSU users (based on numerous
and repeated complaints when we used the system recently) it's not a
very smooth process... but if instead of having to make up this new
account that you'll only ever use for one thing, you now get to use an
account you already have, and instead of having to enter your name
(address, etc.), OAuth / OpenID says "hey this application wants to
access your name and address, is that OK?" ... much simpler, smoother
for the user.

For strictly internal applications, the existing Sentinel system would
continue to be used. Application developers would be able to configure
which types of IDs are accepted. There would still be an OAuth
wrapper, so that users would be clearly notified which data was being
used, which currently with Sentinel apps is up to the developers to
request permission and the Sentinel team to approve, with no
requirement to disclose to users exactly what you're doing. Not that I
don't trust my fellow developers, since the Sentinel API does allow
access to certain sensitive data (SSN) when approved, I would very
much like to know that an application is accessing my SSN.

Carl Bussema III
Information Technologist
Michigan State University Outreach & Engagement
Phone: (517) 353-8977 • Fax: (517) 432-9541
[log in to unmask]



On Wed, Mar 21, 2012 at 3:53 PM, Paduch, John <[log in to unmask]> wrote:
> 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:[log in to unmask]]
> Sent: Wednesday, March 21, 2012 3:42 PM
> To: [log in to unmask]
> 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:[log in to unmask]]
> Sent: Wednesday, March 21, 2012 2:10 PM
> To: Troy D Murray
> Cc: AIS Sentinel Support; [log in to unmask]; Fowlks, Kevin;
> [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:
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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:[log in to unmask]]
> Sent: Wednesday, March 21, 2012 11:13 AM
> To: Murphy, Patrick
> Cc: AIS Sentinel Support; [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:
>
> 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.
> 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.
> My application at this point requests temporary credentials (aka Request
> Token) from your server which are provided.
> 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.
> 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.
> 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).
> If the user approves, your server then marks the temporary credentials (aka
> Request Token) as resource owner (user) authorized by the user
> 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).
> 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:
>
> 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.
> 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.
> Your server contains a list of all approved client applications
> (web/desktop/etc), like my application, that can use MSU OAuth.
> 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).
> 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.
> 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 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: [log in to unmask]
>
> 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:[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
>
> E: [log in to unmask]
>
> 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:[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
>
> E: [log in to unmask]
>
> 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
>
>
>
>