Authentication Is Good, Trust Is Better. What About Trusting Delegated Identity?

As we know authentication is the fundamental part of identity management (IdM) and serves to verify claims giving the right level of access. IdM encompasses different functionalities such as identity lifecycle management, authentication management, permission management or delegates the verification. Despite the fact that companies change, get reorganized, implement BYOD management or move away from traditional closed business models to open models, it’s up to the IdM to deal with a series of risks such as privacy aspects, trust relationship or regulatory compliance. Trustworthiness in IdM is perhaps the most important aspect and therefore the identification and authorization process is critical to gain access to protected resources. In this context, the NIST constantly provides technical guidelines for digital identity and authentication describing different levels of authentication strength in the areas of identity proofing, tokens, authentication process or assertions. Recently, these technical authentication guidelines have undergone significant updates including major changes such as the deprecation of over the air one-time passcodes, defined acceptable use of knowledge-based verification, specified acceptable password policies and reviewed the identity proofing requirement (NIST Special Publication 800-63A. 2017). The major change is the shift from the traditional contentious topic of the four levels of identity assurance (Electronic Authentication Guideline, 2011) to an identity standard that offers more options to get assurance level. Levels of assurance are now decoupled from individual parts, namely the assurance level for identity proofing (IAL), the authentication process (AAL) and the assertions protocol used in the federated environment (FAL). This split enables companies to associate the identity assurance with credential strength and thus ensuring that sensitive data is better protected.

Independently of the authentication factor, identity validation is made of collecting digital evidence, determining the authenticity to the real subject and establishing a trusted relationship. Whether we try to pair a remote control to our GoPro through a PIN displayed on the LCD, activate the digital wallet of our smart phone through out-of-band activation or perform a Single-Sign-On (SSO), the goal is always the same: obtaining subject authenticity assurance. SSO using Security Assertion Markup Language (SAML) for example is a typical example of a strong relationship between Service Provider (SP) and Identity Provider (IdP). Through the exchange of SAML metadata, the SP can trust the IdP.

Figure 1: circle of trust

While we can trust digital identity if we have a certain level of confidence in the asserted identity, delegating the identity violates the security principle of least privileges and so it changes the perspective on established trusted relationships.

The reasons for leveraging identity delegation are multiple. The system administrator might use identity delegation to perform specific operations on behalf of the user whereas in a social context, identity delegation allows people to move freely, use shared resources and make information ubiquitously available. The implementation of identity delegation reduces the password sharing between users and third parties and promotes the so-called "anti-password pattern". Hence, in the identity delegation model we have new roles: a delegator, who delegates his authorizations and the delegate, who receives the authorizations. In the OAuth and OpenIDConnect (OIDC) world, these roles are covered by the Resource Owner (RO) and the Client. 

Figure 2: identity delegation

It is here where the “magic” between the delegator, delegate and service provider with apparently no trusted relationship happens. From the user’s perspective, the delegator is just concerned with who he/she should delegate to and which authorization to receive on the user’s behalf. Therefore, we need to distinguish between the identity that performed authentication and the effective identity that is subject to access control restrictions.

When using the delegated authorization protocol OAuth 2.0, various authentication flows are supported. Traditional user password, OIDC JSON Web Token (JWT) authorization (JSON Web Token JWT, 2015) or signed SAML 2.0 Assertion are all valid authentication mechanisms to determine the valid identity. It’s another story when it comes to effective identity that accesses the protected resources. Either granular access control is applied with OIDC information provided in the first place, or the delegator and delegate are involved in a social OAuth dance in order to gain an access token. A typical social login between SlideShare and LinkedIn is represented below (Figure 3) where the user tries to access protected resources (Slideshare) with delegator (LinkedIn) credentials.

Figure 3: typical social login authentication process

Considering this crucial step, we have to take the following into account that:

• Any registered IdM account (LinkedIn) can access the service provider (SlideShare)
• The service provider (SlideShare) is a trusted entity
• The delegate potentially accesses delegator’s confidential information
• The delegator owns an account and trust the IdM (LinkedIn)
• The delegator accepts the security policy

It is defensible that it is the delegator’s responsibility to understand and uphold the security policy, but at the same time, this step can lead to a dangerous security decision. Although the scope domain for the delegate is restricted and the access duration is limited, the user’s privacy is de-facto at risk and control of the application is handed away moving the liability to the delegator.

The division between identification and authorization are important topics in IT-Security and in this situation, the identity delegation model is exceptional. However, despite the different assurance level classifications, the service providers that undergo this model supported by delegation protocol must consider the specific trust assumptions and the threat model.