1 / 2

Trust Elevation with UMA and OpenID Connect

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.

gluu
Download Presentation

Trust Elevation with UMA and OpenID Connect

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. Gluu’s 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 it’s 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 Gluu’s 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.wordpress.com/2014/05/16/how-to-benchmark-ox-for-a-large-scale-deployment/

More Related