Federated Command Line Client Authentication with SimpleSAMLphp and OAuth
Feide RnD is more or less Andreas Åkre Solberg's thoughs about Identity Management. Anderas Åkre Solberg works in the Feide project at UNINETT.
I’ve added OAuth support in a module in SimpleSAMLphp and made a proof of concept demo on how to perform authentication initiated from a command line client.
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’.
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.
- Client gets a request token from the server. (back-channel) OAUth
- Clients will open a web browser or tell the user to manually go to an endpoint on the server containing the request key.
- At this web-based endpoint, the user follows normal WebSSO SAML 2.0 until the user ends up authenticated.
- User is told to click continue in the client.
- 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.
- Client do a back-channel request to the userInfo endpoint using the OAuth access token, and gets user attributes back in an JSON array.