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

André_Rohrbach_beitrag
Digital first! Jetzt wirklich?

Wie man Digitalisierungsinitiativen zum Erfolg führt, indem man den Menschen miteinbezieht. Der Energiedienstleister ewz überträgt Verantwortung in die Teams, um den sich verändernden Kundenbedürfnissen gerecht zu werden.

Mehr erfahren
Lead Code Camp
Das dritte Code Camp stand ganz im Zeichen der künstlichen Intelligenz

Beim dritten Code Camp von ti&m drehte sich alles um das Thema künstliche Intelligenz (KI). Mehr als 20 Entwickler kamen zusammen, um ihr Wissen in der Technologie zu vertiefen. In 30 Stunden Programmieren lernten die Teilnehmer, was mit KI alles möglich ist.

Mehr erfahren
Robo Advisor Sparkonto 750x410
Warum Robo Advisor an Sparkonten scheitern

Robo Advisor stellen inzwischen keine Innovation mehr dar. Bereits vor über 10 Jahren wurde davon gesprochen und seit 2009 ist der erste digitale Berater in der Schweiz im Einsatz. Bisher wurde aber der physische Berater nicht ersetzt, noch konnte die grosse Masse der Schweizer Sparkontobesitzer zum Anlegen bewegt werden. Wie also können Robo Advisor einen Mehrwert für den Endkunden bieten?

Mehr erfahren
2017_06_Rimle-Postauto
Autonome Postautos: unterwegs mit der Zukunft

Autonome Fahrzeuge // Die autonomen Postautos haben keinen Fahrer und können dank ihrer leistungsfähigen Sensoren problemlos navigieren. Zum ersten Mal testet ein Unternehmen diese Technologie in der Schweiz im öffentlichen Raum.

Mehr erfahren
Self-Sovereign 750x410
Self-Sovereign Identity in der Blockchain

Mehr erfahren