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.
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:
- 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.
- 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.
After the User Managed Access 1.0 specifications have been finalized, our engineers are running at full speed. I managed to get...
The User-Managed Access (UMA) Version 1.0 specifications have been finalized as Kantara Initiative Recommendations, the highest level of technical...
As chair of the Kantara Initiative’s User-Managed Access (UMA) Work Group, I’m pleased to say that the group has...
Take HEART: New standards group for security, privacy, and authorized sharing of personal health data
Do you have a stake in solving issues of security, privacy, and authorized sharing of individual health data in...
Privacy and User Managed Access – an interview with Eve Maler, ForgeRock’s VP of Innovation & Emerging Technology
A recent report published by Pew Research (titled: Public Perceptions of Privacy and Security in the Post-Snowden Era) has...
Welcome to the OpenUMA community on ForgeRock.org! This community centers on the emerging User-Managed Access (UMA) standard, part of the...