On 30. april2009, at 15:36, Tom Scavo wrote: > > 2009/4/30 Solberg Andreas Åkre <andreassolb...@gmail.com>: >> >> proof of concept >> >> https://rnd.feide.no/content/federated-command-line-client-authentication-simplesamlphp-and-oauth > > Can you outline the protocol flow, please? You're obviously not using > SAML Web Browser SSO between the SAML SP and the IdP. What protocol > are you using?
The Background The Identity Federations that we work with is more or less entirely based upon WebSSO. From time to time we get requests from people wanting to re-use the widely deployed WebSSO framework for applications that are not Web-based. it could be stand-alone GUI applications or command line clients. Recently, I got a question (from the GRID world) about standarizing the `name` of the `Input` elements in the HTML of the login pages across Identity Providers, to make it simpler to webscrape the login pages to provide federated login to a command line client. In the following section, I'll try to expain my approach to 'a better way of doing it'. My approach You have a client-server architecture with a non-web based client, and you want to re-use WebSSO infrastructure. Usually the client wants to get some personalized data form the server, and the client must prove towards the server that it represents a specific user. The client implements OAuth Consumer capabilities. The server implements both an OAuth Provider and a SAML 2.0 WebSSO Service Provider. 1) Client gets a request token from the server. (back-channel) OAUth 2) Clients will open a web browser or tell the user to manually go to an endpoint on the server containing the request key. 3) At this web-based endpoint, the user follows normal WebSSO SAML 2.0 until the user ends up authenticated. 4) User is told to click continue in the client. 5) Client exchanges the request token with an access token with a call to the server (back-channel) OAuth Now, we are sure that both the client and the server represent the same user, and the access token can be used to communicate, referring to the user behind the client. If the server is the only entity that needs to know the identity of the user, the client can now request the data it needs. If the client itself also need to know who the user is, some extra steps is neccessary. I implemented a very simple WS getUserInfo endpoint at the server, that uses OAuth, and returns user attributes as a JSON array. 6) Client do a back-channel request to the userInfo endpoint using the OAuth access token, and gets user attributes back in an JSON array. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
