Trust Elevation with UMA and OpenID Connect

1
Trust Elevation with UMA and OpenID Connect

• With the impending explosion of strong
  authentication technologies due to the
  development of standards like FIDO, it is
  critical that Web and mobile developers can
  support trust elevation (or stepped-up
  authentication) using existing federation
  protocols, with minimal effort.
•  
• Gluus open source OX Project implements the
  proposed UMA standard to provide an OAuth2
  solution for Web access management (WAM). The
  use case is more fully described in the Case
  Study Enterprise Access Management 2.0 on the
  Kantara site, or the draft UMA standard.
•  
• If a person authenticates at an OpenID Connect
  domain, the strength of the authentication can be
  derived from the acr or amr parameters of the
  OpenID Connect ID token. The amr may contain a
  list of authentication details such as '10',
  'sms-token', 'basic'. The conventions for the
  values of the acr and amr id token claims may be
  defined by the domain.
•  
• The starting point for UMA is when the API is
  called. Authentication has already happened. The
  AS may decide in an UMA policy that a specific
  acr or amr is required for authorization to be
  granted to the API or folder.

2
Normally, if authorization is not allowed, a HTTP
403 status is returned. However, it would be
helpful if the AS could send some extra
information so the Relying Party (RP) would
know that the person was not authorized because
stronger authentication is required (and it can
follow a re-direct to get to the
re-authentication, if the person wishes.)   This
behavior was not defined in UMA, so Gluu proposed
a profile for UMA Trust Elevation.   One of the
benefits of this solution is that it is friendly
to both Web and native applications. Also, UMA
itself is neutral on how the person is
authenticated, so its conceivable that a profile
for SAML could also be defined.   Gluu has a
rough work-around for mixing SAML authentication
and UMA policies. For example, it is going to be
increasingly common that your partner may have a
Microsoft ADFS SAML IDP. In Gluus workaround, we
use a SAML proxy to consolidate the backend IDPs,
and we use the Apache agent to send the
attributes in the HTTP Request to the AS. This
requires that the RP is trusted by the domain
(like a SiteMinder agent). Using this approach,
the authentication mechanism can be specified
per SP. So trust elevation is possible per
application with SAML but not per folder as in
UMA.   Article resource - http//thegluuserver.wor
dpress.com/2014/05/16/how-to-benchmark-ox-for-a-la
rge-scale-deployment/