Invitation Based Authorization in Federated Systems

INVITATION BASED AUTHORIZATION IN FEDERATED SYSTEMS

Jaime Pérez Crespo

RedIRIS Middleware Engineer, Bronce building, Manuel Gómez Moreno square, 28020, Madrid, Spain

Research paper

Abstract

Identity federations are growing faster and bigger in the academic networks. Once solved the main problem of being able to interconnect services with identity providers and making them talk a common language to exchange attributes describing the identity of a user, current research is focused on the next high level features that should be provided by those kind of architectures, that is, attribute aggregation and authorization mechanisms. This paper examines a practical solution to provide service administrators with an external, distributed way of authorizing their users, simpler to deploy than the current approaches, compatible with group management tools, and finally easier to use for both users and administrators.

Keywords

Authorization, federations, attributes, invitations.

1. Introduction

The first step to include an application in an identity federation consists in distributing identity across the federation and being able to connect services with identity providers, so that they can assert the identity of the users to anyone requiring it, via a common language. This is the basic feature that every application needs: to know who is using it, and to ensure users are really the ones depicted by their electronic identities. That’s what we know as authentication.

But authenticating users is not enough. Typically, users won’t be enabled to access every resource they can identify to. Or at least, that’s not something desirable in the real world. Service provider administrators demand the capability of allowing access to their resources only to a subset of users in the federation. The goal is to determine if some previously verified identity is allowed to do something. That’s called authorization, and obviously relies on a proper previous authentication.

The problem with authorization in a federated environment is to find a compromise between the usability for end users and the fine-grained control that service administrators demand for their resources. Most production services that offer a federated login tend to perform authorization based on the attributes received for the users, blindly trusting identity providers, and assuming that if they give some set of attributes once authenticated, they are really supposed to have them. And that’s correct, at least from a theoretical point of view.

While some federations are supposed to be cooperative architectures where each partner must commit to follow some strict behaviour guidelines and sign them in order to be allowed into the federation, there are other federations much more relaxed in what relates to requirements, though. The line separating both approaches is blurry and sometimes even nonexistent, since federations tend to join together, no matter what requisites they ask their partners, and therefore it’s hard to have any guarantee on what you can expect, as a service provider, from the users identifying to your applications. As a federation grows, either by subscribing more partners or by interconnecting to other federations, the probability of finding a mistake in someone’s identity grows too, no matter if it was caused intentionally or not.

That was the easiest and quickest way to proceed some time ago, when identity federations were starting up, since the first services that joined used relaxed authorization rules and the cost of implementing them (that is, requiring identity providers to supply some sort of attributes) was very low with just a few identity providers. But we no longer have everything under control. More and more services join everyday our federations, and the number of identity providers grows even faster, so we need to go further in our research and find a better way to implement authorization, as the initial approach simply does not scale.

2. The authorization problem

As we have already depicted in the introduction, the current authorization mechanisms inside identity federations imply lots of work for administrators of both the identity and service providers. And what’s even worse, they are not reliable enough as trust relies on identity providers which can misbehave, so services does not have a way to perform any further authorization. Of course a federation can have mechanisms to discover and solve any bad behaviour from any partner, but from the service provider’s point of view, the federation should provide those mechanisms not only to audit who did it wrong, but also to avoid him doing it. You may want to track down the one allowing unauthorized people to access your services, but it may not be enough once the damage has been done, especially if you are running a critical, highly restricted application. If you want to make your application, with loads of private, sensible data, available through a federation, then you’ll want to ensure that only authorized users are granted access. The question, therefore, is how to provide service administrators with such capability to satisfy their control requirements.

The consensus used to develop pilot and production identity federations as of today was to use some specific attributes to determine which applications a user is entitled to access to. This way, applications can check those attributes and make any authorization decision in terms of the values presented for them. In academic federations, that’s usually the eduPersonEntitlement[1], which contains a set of values describing resources the user should have access to within the academic environment. The format of those values may vary between federations, but typically URNs (Uniform Resource Names) are used. As previously explained, this is a quick approach when dealing with just a few services and identity providers, but it simply does not scale as more and more entities join the federation, because:

It is difficult to deploy in large federations, as it requires administrators of the identity providers to continuously add new attributes for their users and to ensure new attributes will be easily released across the federation. When only one or a few institutions manage all identity providers, it may be feasible, but when different institutions control each identity provider, it becomes impossible to deal with every administrator, especially when maintaining the connection to the federation is not one of their main concerns. And unfortunately, that’s a usual problem in academic environments.

The consequence is that end users, the raison d’être for every federation, see identity federations as something annoying, tricky and hard to deal with.

Identity providers hold the responsibility for the attributes, thus authorization depends heavily on them. This means the rules that govern who is entitled to access a resource are not established by service providers themselves, but by third parties instead. This poses undesired security risks that may prevent service providers to join federations in the future, as their perception would be that the federation does not provide them with the desired tools to control who has access to their resources, and therefore any error, no matter if intentional or not, can lead their applications and data to a compromise.

3. Design of a possible solution

Our proposal is based on the idea of making authorization user-centric, so it’s made on a per-user basis. Users are identified by means of their electronic mail addresses, which are guaranteed to be unique and persistent (of course that’s not completely true, since e-mail addresses can be created and deleted, but it can be agreed that such addresses are persistent enough to be used for a relevant time lapse, and have the side benefit of adding extra semantics: one address identifies not only a single individual, but also a relationship he or she holds with an organization). Since e-mail is a common attribute like any other, and it shouldn’t be required in order to keep the privacy of the users, some mechanism to link it with a set of attributes in the context of the federation must be established. Therefore, our approach consists in a system relying on the well-known e-mail verification scheme, which is widely extended over the Internet and its higher-level applications, like forums and mailing lists. It makes sense, since those applications use the e-mail verification as part of the registration process, and our mechanism can be seen as something analogous.

3.1. Protocol outline

The basic use case that depicts the whole system is quite simple and easy to use, for both end users and service administrators:

First of all, the administrator of the resource (or any other individual entitled to do it) sends an invitation to an e-mail address or a bunch of them, through some common interface (which can be web based or even command-line).
Every invite triggers an e-mail to be sent to the user with detailed instructions on how he must proceed to get authorized, providing a specially crafted URL that will authorize the user once logged in. The system generates a random identifier, which is recorded in a database, associated with the e-mail address of the user for whom the invite was sent. This identifier is also part of the URL sent to the user, so that the system will be able to track it down once the user authenticates.
The user receives the e-mail and follows the link, reaching out the application, which will then force him to authenticate by means of the federation. Please note that this will be a special requirement for those services that do not trigger authentication automatically by default, like for example a wiki that allows anonymous users to read its contents but enforces them to identify only if they want to write something.
The user gets redirected to his identity provider, usually after being asked to select it on some web page (usually called DS or Discovery Service). He identifies himself there, either by using his username and password, by giving a certificate, or any other method his identity provider supports.
Once verified the identity of the user at the identity provider, he is redirected back to the URL he was provided with in the invitation e-mail.
Once back in that URL, which can be either a custom entry point of the application or even an independent one, the system will track back the invitation and search for some common attributes presented by the user.
If the invitation is registered and the user gives at least one of the expected attributes or combinations, then he is recorded automatically as authorized, and will be entitled to access the resource from now on, since he will be always identified with the same attributes.

It’s important to say that the attributes used to identify users across different login sessions, or their combinations, must be persistent (at least from the point of view of the application) and unique in the whole federation. Since an identity provider can’t guarantee their attributes not to be found in any other provider, the recommended approach would be to combine an attribute that is unique for a certain institution, plus another one identifying the organization itself. In academic federations, the eduPersonTargetedId[1] is widely used to identify users so that there won’t be collisions within the same provider, plus the advantage that it is an opaque identifier (a random character string or a number, for example) and targeted to the specific resource, so that users cannot be tracked down across different applications and therefore their privacy will be preserved.

Fig. 1: Invitation protocol use case.

3.2. Benefits

The protocol described here has the advantage of allowing the authorization of almost any individual logging in through a federation. As no specific attributes are required to identify the users, except a few, opaque ones, that the federation can recommend or even require, the administrators of identity providers don’t have to bother continuously about adding new attributes for their users. Additionally, the service provider can easily revoke authorization if there is evidence of abuse by the user, or even if that’s the usual behaviour (for example subscription oriented applications, like library ones), without intervention of the identity provider required.

On the other side, this approach is compatible with other modern mechanisms becoming very popular in federations, like group management tools and attribute aggregation. In fact, it can be used even with traditional attribute based authorization schemas, since a service administrator can store specific attributes (like for example the eduPersonEntitlement one) in a separate storage, so that users no longer have all their attributes located at their identity providers, but distributed across multiple attribute authorities instead. This way, authorization can be a process of gathering attributes from several sources once the user is authenticated, putting them all together and making decisions based on the complete set of attributes collected for him. Since identity providers will no longer hold all the attributes, system maintenance is easier and transparent for both, end users and administrators of identity providers.

In conclusion, such design allows service providers to completely control who is entitled to have access to their resources, being able to be as fine-grained as needed, and avoid any human or technical mistake leading to a potential damage of the application or leakage of its data. While authorization can still be done with any suitable mechanism, we introduce a protocol that helps administrators to authorize users individually before actually using the service. Therefore, the tangible product of this process is the data that represents the set of individuals entitled to have access to an application, without any limitation on the data representation or even semantics. In other words, we provide the data source for authorization, and the authorization engine may then use it to make decisions.

4. Security considerations

4.1. Security risks

Although the architecture detailed here provides a simple solution for the problem of authorization in federated environments, it implies undesired security risks and problems that we must take into account. Here we present a rough draft of those security problems that may arise in such architecture:

If the links sent to the users inside the invitation e-mail do not expire, a user may be able to cheat the system by simply sharing them with other colleagues, allowing them to authorize themselves although they were not the targets of the invitation.
Users of a federation may be impersonated if someone intercepts or steals their invitations, even if the authorization links expire, being able to use them before the legitimate user.

4.2. Countermeasures

To avoid or mitigate the problems described above, we recommend implementing the following security countermeasures:

Links given to a user as part of an invitation must be one time URLs. References to an invitation that has been already accepted must be removed, so that any link referring to an unregistered invitation will never authorize the user following it. If a link referring an unknown invitation is used, applications should:
If the authenticated user was previously authorized according to the attributes he presented, consider him allowed and skip the authorization process, redirecting him directly to the application entry point.
Otherwise skip the authorization process, log the error as a possible break-in attempt, and notify the administrator to take the appropriate actions.
Require always at least one attribute whose value is computed on the basis of an institutional e-mail address. Although the attribute can be opaque so that the privacy of the users is kept safe, the system will be capable of correlating the e-mail address recipient of the invitation with the value of the attribute obtained from the federation. Of course, this means that institutional e-mail addresses must be used as the recipients of invitations, and institutions must provide such attribute with all the computed values needed for all the e-mail addresses of the user, if more than one.

It’s recommended to use one-way functions like MD5 or SHA-1 algorithms to compute the value of the attribute, so no reverse calculation is possible and the e-mail address remains unknown. This way, impersonation frauds can be detected by checking the original e-mail against the attribute received:

The invitation system may store the e-mail address of the user and an invitation reference, both attached to each other.
When authorization is triggered by means of a user following the invitation link, the system must recover the e-mail address associated with that invitation reference, and search for the specific attribute expected to hold the transformation of the e-mail address. If more than one algorithm is allowed, there should be some way to recover the method used to compute the attribute by the service provider into the attribute value itself. Then the system will apply the same algorithm to the e-mail address of the user and compare to the value received.
If the value computed is the same than the one received, then the user is supposed to be the one that was originally invited and therefore authorized.
If the value computed differs from the one received, authorization is denied, the error is logged and the administrator notified.
If the expected specific attribute is not found, the authorization is denied and the user notified about the problem to require his organization to provide such attribute for him.

These measures do not avoid all possible frauds that may occur inside a federation, since we still trust attributes coming from an identity provider that can be forged to match the ones expected by the system, although they make it considerably harder to cheat. Anyway, authorization is now dependant on receiving at least one invitation, so service providers can implement their own security measures to prevent invitations to be misused, and they do have control over who and when is entitled to access their resource.