There are multiple efforts that are going on to bring the federated identity to non-web protocols. At IETF, it is done in the kitten WG and here are projects like Moonshot that deals with GSS-API etc. That is the right way to go in the long run.
At the same time, there is a question on what shall we do in the interim, before GSS-API support gets ubiquitous among the different clients.
In PEAFIAMP project, we are trying to address it as well.
The basic idea is to put the access token in the password field.
There are other pre-requisites such as:
- Mapping the local user (e.g., mail user ) in the system to the federated user.
- Federating the permission within the password length limitation.
The first issue is dealt at the first time account federation (on-the-fly provisioning). The service, e.g., MAIL provider, should provide a web interface to let the user federate the accounts.
Now that the email account is linked to the federated account, user can actually ask for the client specific “password (access token)”.
It starts with the MailWeb again. This time, the user goes to the get password page. There he inputs the name of the client that he can remember (e.g., “my iPhone”), and press the “request password” button. Since the MailWeb already knows the federated user, and thus the identity provider, it redirects the user to the identity provider with id_token as the user_hint.
Then, (if the user does not have the session) the user gets authenticated at the IdP, and instead of sent back to the site, the access_token is shown on the web page, which he is instructed to copy and paste to the mail user agent’s account settings.
The access token in this case is a pseudo-opaque string (TBD: if it can hold the IdP address, it will make it possible to use multiple identity providers) that acts as an artifact / reference to the permission list. When the mail server receives it and send it to the PAM module, the PAM module sends it to the token introspection endpoint at the IdP to get the validity and scope (read, read+send, (read+delete, read+delete+send)).
This scheme can also be used for other clients, such as SSH, or in the case of high performance computing platform, it may provide the PEM encoded X.509 certs as the access_token.
True, it is a hack. But it solves the current problems, till the proper way propagates.