You know that blue “Share” button in Google Apps? Ever wanted to add a feature like that to your own app or API ecosystem? The UMA protocol enables you to do just that.

User-Managed Access (UMA) is an OAuth-based protocol that enables an individual to control the authorization of data sharing and service access made by others.

The OpenUMA community shares an interest in informing, improving, and extending the development of UMA-compatible open-source software as part of ForgeRock’s Open Identity Stack.

The UMA Standard explained

The UMA standard

UMA defines how resource owners can control protected-resource access by clients operated by arbitrary requesting parties, where the resources reside on any number of resource servers, and where a centralized authorization server governs access based on resource owner policy.

UMA can be considered an application of OAuth 2 in that it uses, profiles, and extends OAuth to enable various use cases for resource owner-managed access (the UMA specification calls itself a profile of OAuth 2). UMA’s main flow superficially resembles plain OAuth, and it has embedded subflows that really are instances of ordinary OAuth. While UMA looks OAuth-ish, it functions most like a standardized, API- and scope-aware version of a web access management system — where the policymaker may be an organization as usual, or an individual acting on his or her own behalf.

In short, the UMA protocol lets you add interoperable authorization, access control, privacy, and consent features to your application ecosystem.

Get Involved!

The OpenUMA community shares an interest in informing, improving, and extending the development of UMA-compatible open-source software as part of ForgeRock’s Open Identity Stack.

You are welcome to join the community. You can register to join right now to engage with us!

Currently no open-source OpenUMA code has yet been published, but keep an eye out in early 2015! If you are a developer interested in OpenUMA, stay tuned for opportunities to get the source, report issues, describe requests for enhancements, edit wiki documentation, and discuss your work on our developer mailing lists.

Source code

The OpenUMA source code in development can be explored here:

Sample Use Case

Sample Use Case: OpenUMA Delegated University Course Registration

University students are on the go — and if you’re the parent of one of them, you might be called upon to help them with tasks such as registering them for courses as the new semester approaches, even if they’re on a semester abroad or a research trip and have spotty Internet access in their jungle, desert, or swamp environs.

We spoke to the information technology department at Brigham Young University, which faces big challenges in this area.

Brigham Young University, like other US universities, is subject to Family Educational Rights and Privacy Act (FERPA) legislation, which is similar to HIPAA privacy legislation but in some senses more stringent. It protects adult students from disclosure of information to parents without their consent.

At the same time, it needs to provide a capability for a parent or other third party, such as an advisement counselor, to help a student register when the student has no online access.

The university has provided this capability in one of two ways:

  1. Through acknowledging that access sometimes happens implicitly through “consensual impersonation”, when a student shares his or her account username and password with a parent for registration purposes.
  2. In order to avoid impersonation, providing a special-purpose “act-as” feature where a parent acquires a login account and states which child he or she wishes to act on behalf of in registering for classes. The student must approve the parent’s request.

Implicit “consensual impersonation” is:

  • Dangerous security-wise because it exposes the student’s credentials to a third party and gives the parent total access to the student’s account, opening up the university to unwanted liability. The student will have to resort to changing his or her password in order to “revoke access” granted to the parent.
  • Short-sighted architecturally because as stronger methods of authentication that add factors on top of password-based authentication become more viable and popular, password-sharing will no longer work.

Explicit “act-as” functionality is:

  • Awkward in the user interface because the parent is given access to too much information in the student’s account and because a parent may have to select which of potentially several children to impersonate in the course of each login session.
  • Awkward architecturally because the parent’s actions are an “impersonation overlay” for the student’s.
  • Short-sighted architecturally because it’s difficult to extend to an ecosystem of different kinds of web and native applications that could call the same course registration API.

Protecting the university’s course registration resource server with an UMA authorization server would let Alice set sharing preferences that enable her father Bob gain access to the course registration system, setting up her course schedule when she’s not around.

On further examination, it also turns out to be valuable to define finer-grained scopes than first existed in this system; some requesting parties would find mere “view” access to be valuable, some (students and their designees) need ordinary “register” access, and some (university administrators) require special access that lets them take actions that ordinary students wouldn’t ever have access to, such as waiving prerequisites for certain courses.

UMA enables a robust solution whose architecture supports security, privacy, regulatory compliance, and even improved user experiences and wider app ecosystems.


The student’s goal is to enable others to securely register him or her for classes when he or she is offline. The university’s goal is to adhere to FERPA privacy regulations in giving auditable constrained delegated access to student data while making registration possible, and to build apps — and make it possible for a wide variety of others to build apps — to a robust security architecture. The other requesting parties’ goal is to assist the student as required.


Infographic: OpenUMA and the Future Role of OpenAM

The following diagram summarizes the UMA protocol flow. OpenAM will play the role of an UMA authorization server, and your application or API makes available the resources that you want to protect on your users’ behalf.

OpenUMA blog posts

©2017 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your username and password

Lost your password?

Forgot your details?