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.

1. Client do a back-channel request to the userInfo endpoint using the OAuth access token, and gets user attributes back in an JSON array.