03. Mai 2017

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

Trust 750x410

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.

Table 1: NIST Assurance Levels (Source: NIST Special Publication 800-63A. 2017)
SP 800-63A Enrolment and Identity Proofing
Level Description
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
Level Description
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
Level Description
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.

Rainer Knupfer
Rainer Knupfer

Rainer Knupfer is a Lead Engineer at ti&m, graduated in Computer Science and IT-Information Security and has accumulated the right mix between education, consulting experiences and hands-on jobs. He's particularly interested in different aspects of technical security applied to software integration and development in different domains such as digital payment, security authentication design, regulatory compliance and omni-channel applications.

Ähnliche Artikel

Impressionen von der App Builders Switzerland
Impressionen von der ersten App Builders Konferenz der Schweiz

Die Schweiz hat mit der App Builders Konferenz einmal mehr bewiesen, dass sie ein iOS-Land ist. In diesem Artikel geht es um die Impressionen der „App Builders Switzerland 2016“, der ersten Schweizer Konferenz von Entwicklern für Entwickler in Europa.

Mehr erfahren
Die Digitalisierung braucht agile Strategieprozesse

Althergebrachte Strategiezyklen werden den Anforderungen an die digitale Welt nicht mehr gerecht. Transformationsprozesse stellen völlig neue Anforderungen an die Art und Weise, wie die Strategie in Unternehmen entwickelt werden muss. Ständige Iterationen machen den Unterschied.

Mehr erfahren
Contact Tracing in Singapur – eine (digitale) Erfolgsstory

Coronamassnahmen // Singapur hat die COVID-19-Krise aus heutiger Sicht sehr gut gemeistert. Die Massnahmen der rasch handelnden Regierung wurden technologisch durch «SafeEntry» und «TraceTogether» unterstützt. Aber auch in Singapur ging die Krise nicht spurlos an Gesellschaft und Wirtschaft vorbei.

Mehr erfahren
Lazy Angular: Writing Scalable AngularJS Apps
Lazy Angular: Writing Scalable AngularJS Apps

There are two major issues I have faced in the past few years, when writing AngularJS applications, and I have seen numerous other teams fighting the same battles. Out of these experiences the “Lazy Angular” approach came to life. It gives us a project structure which works for both, large and small applications. And it enables us to keep a somewhat consistent load time as new features come to life and our app grows.

Mehr erfahren
Wie „Joy“ das Einkaufserlebnis revolutionieren wird
Wie „Joy“ das Einkaufserlebnis revolutionieren wird

Nachdem das Jahr 2015 aus unserer Sicht als das Jahr des digitalen Portemonnaies zu Buche schlug, überlegten wir uns, wie wir die Akzeptanz des digitalen, bargeld- und kartenlosen Bezahlens an öffentlichen Verkaufspunkten fördern könnten. Geboren war die Idee einer virtuellen Registrierkasse, welche jegliche Art von digitalen Geldbörsen unterstützen würde.

Mehr erfahren