Federated Identity for non-web apps

Session Topic:Federated Identity for Non-Web Applicants (T2F)

Convener: Klaas Wierenga

Notes-taker(s):David Robinson

Tags for the session - technology discussed/ideas considered:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

There were two separate topics under this same session title. One discussion was around native applications running on mobile devices and how they interact with providers.
The other discussion was on the IETF Application Bridging for Federated Access Beyond web (ABFAB) technology.


Details: Use Case To Start Discussion: Company A is a contractor to Company B. Identities are federated between the two companies. User from Company A performs an activity that requires Company B to contact Company C for data.

How does this work?

The statement was made that "simple service chain is not solved by the federated identity solution". The military as worked for 7 years on this chaining problem and has not solved it. Federating identities across trust domains may not be the best solution. Instead, tokens should be considered as a way of solving this problem - something like bearer tokens.

The same use case was applied slightly differently for the next part of the discussion. Assume the use case is a person accessing pieces of their personal data from the government and a health provider - but they want to pull attributes from different places into a coherent picture. It was stated that current technologies assume browser redirection for this use case which doesn't work well with a native phone application. The premise of this statement was a user is forced into a browser in order to solve the federated identity problem - they cannot stay in a mobile native application because the protocols assume browser redirection.

Further the problem was stated to be bigger than protocols that require redirection...that federation between downstream providers does not work effectively. It was mentioned that personal data stores are an approach to solving the described problem and that UMA had solutions that addressed the use case described. Delivery of data can be via OAuth and there is no technical reason that browser redirection has to happen. It was suggested that the government of British Columbia had solved the use case being discussed using existing technologies. BC used tokens to restrict access/authorization and used signatures to prove where the data came from.

It was mentioned that various services also have different API interfaces which makes downstream federation difficult.

It was mentioned, as an example, that Chrome makes the browser the operating system and addressed the "native application" concerns in some ways - and that in general, discussions about tighter integration between browsers, operating systems and hardware might address concerns with browser redirection (not necessarily chaining).

There was also discussion about what information each downstream provider has. Some have authentication information but they lack the meta data to effectively tie information together from downstream providers. Downstream providers may have more meta data...but since they are downstream and don't control the federation, the "tying" is left to the mobile application - which is not tenable.

Browser cookies may help provide useful information that ties these chains together...but it was stated this was not available in native mobile apps.

There was a brief side discussion on if users' actually like federated identities. One point of view was user's prefer to have their information with one or a small number of providers so they can understand under what conditions others can access their information.

There was concern that with federation, undesired correlation can take place on a user's information. The conversation completed shifted to IETF Application Bridging for Federated Access Beyond web technology (ABFAB).

With this architecture and set of technologies, it is possible for a university student at one university to use a non-web based application at another university. The idea is that universities can federate identities of students as well as authorization levels to control access to the applications.

ABFAB technology is based on the Extensible Authentication Protocol (EAP), with attribute assertions carried over SAML. It also uses GNU Generic Security Service Library (GSS) and RADIUS. See the IETF web site for more details.

It was stated that ABFAB combines the best of "both worlds". It uses a federation fabric based on RADIUS, authentication based on EAP, attribute assertion based on SAML and application integration based on GSS. It was stated that most Microsoft applications use the GSS API. SAML assertions are carried over RADIUS and EAP is used for user authentication. "EAP is logically through the entire thing and goes end to end to itself".

The two organizations agree ahead of time on what attributes/authorization is available - and this is an NxN set up problem with partners, but one universities are willing to handle for now.