Authentication Is Good, Trust Is Better. What About Trusting Delegated Identity?
Trust in a relationship is a must and this is not only holds true for private lives but also in the virtual life. While trustworthiness for established authentication protocols is mainly based on agreement between entities, certificates and keys, trust in the identity delegation context is ambiguous because the owner might not be the consumer of the API. This post addresses some trust concerns when introducing protocols based on identity delegation that de-facto lead to an identity paradigm shift.
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.
|SP 800-63A Enrolment and Identity Proofing|
|IAL1||No requirement to specific real-life identity. Any attributes provided in conjunction with the authentication process are self-asserted.|
|IAL2||Evidence supports the real-world existence of the claimed identity with verification.|
|IAL3||Physical presence is required for identity proofing.|
|SP 800-63B Authentication and Lifecycle Management|
|AAL1||Some assurance that the claimant controls the authenticator registered to a subscriber. At least single-factor authentication.|
|AAL2||High confidence that the claimant controls authenticators registered to a subscriber. 2-Factor authentication required.|
|AAL3||Very high confidence that the claimant controls the authenticator registered to a subscriber. In addition to AAL2, proof of possession of a key through a cryptographic protocol.|
|SP 800-63C Federation and Assertions|
|FAL1||Allows the subscriber to enable the RP to receive a bearer assertion. The assertion is signed by the IdP using approved cryptography.|
|FAL2||Adds the requirement that the assertion be encrypted using approved cryptography such that the RP is the only party that can decrypt it.|
|FAL3||Requires the subscriber to present proof of possession of a cryptographic key referenced in the assertion in addition to the assertion artifact itself. The assertion is signed by the IdP and encrypted to the RP using approved cryptography.|
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.