ForgeRock Secure Sharing: The Framework
My previous blog outlined how a sharing solution involves trusting people, resources, applications and services, and the access information communicated between a producer and consumer. Let’s turn our attention now to the specific architectures, standards, and technologies that are used to implement an advanced secure sharing solution.
The Kantara Initiative, Inc. developed the User-Managed Access (UMA) 2.0 specification, which describes an open standard for person-to-person resource sharing. UMA 2.0 is an extension of the OAuth 2.0 access delegation open standard specification. This is the framework for ForgeRock Secure Sharing.
The UMA 2.0 architecture defines these roles:
- Resource Owner
- Client
- Requesting Party
- Resource Server
- Authorization Server
Resource Owner
The Resource Owner manages access to resources. This can be a person or or an organization that essentially acts as the producer. Typically, an individual has direct control over their own resources, while organizations have control over a collection of resources. Regardless, the Resource Owner must be authenticated to the Authorization Server. The Resource Owner is responsible for:
- Creation and registration of resources: Maintaining metadata, and, optionally, associating with digital content that may be in an external system.
- Updating policies: Setting resource permissions that control who has access to what and to what extent.
- Handling requests: Approving or denying requests for access to resources.
Client
The Client is used by the Requesting Party to access resources. A Client can be a browser-based application, mobile application, the dashboard of a car, or a smart-home system console. A Client application is generally implemented to support specific organizations or industries. The UMA 2.0 protocol is secure and leverages OAuth 2.0. The Client must be trusted as part of a secure solution and should be an OAuth 2.0 registered client with the Authorization Server.
Requesting Party
The Requesting Party is a person seeking access to a resource, also known as the consumer. They must also be authenticated to the Authorization Server and must use a Client application trusted by the Authorization Server. When a requesting party accesses a resource, they follow this process:
- Use a Client application
- Authenticate to the Authorization Server
- Contact the Resource Server to request permission
- Contact the Authorization Server to get specific approval
- Get the resource from the Resource Server
Resource Server
The Resource Server hosts resources for the Resource Owner and processes requests for resources from Requesting Parties. A Resource Server typically has the following capabilities:
Exposes business- and industry-specific interfaces related to resources
Accepts both manage and access resource requests
Interfaces with the Authorization Server for UMA 2.0, OAuth 2.0 and policies
Interfaces with associated digital content (optional)
Resource Server functionality can be implemented by:
Enhancing an existing resource system
Providing a proxy-type service as a front-end to an existing resource system
Developing a new system
ForgeRock provides an open source UMA 2.0 Resource Server reference implementation project that can be used for testing and development: https://github.com/ForgeRock/frdp-uma-resource-server.
Authorization Server
The Authorization Server protects the resources on the Resource Server. An UMA 2.0 Authorization Server provides a trusted sharing solution that:
Leverages the OAuth 2.0, an industry standard protocol for authorization
Establishes trust with the Resource Server, Resource Owners, and the relationship between a Resource Server and Resource Owner combination
Empowers the Resource Server to issue permission for access requests from client applications
Establishes trust with Client applications and the Requesting Party
Issues resource access tokens for a specific Requesting Party, from a specific Client application, for a specific purpose, mode, or operation
Manages access requests, from Requesting Party submission to Resource Owner approval or denial
Provides services for the Resource Server to validate access tokens
ForgeRock Access Manager implements both the UMA 2.0 specification and the OAuth 2.0 specification. ForgeRock Access Manager provides value-added features for UMA 2.0 resource policy and permission management via both end-user web interfaces and APIs.
The UMA 2.0 architecture is based on two Kantara Initiative specifications:
Federated Authorization: This specification defines a standards-based method for loosely coupling the Authorization Server and the Resource Server in the context of the Resource Owner.
Grant for OAuth 2.0 Authorization: This is a means for a client (application) representing a requesting party to request access to a resource
The UMA 2.0 specifications are used to implement the primary ForgeRock Secure Sharing journeys:
- Resource management
- Resource access
UMA 2.0 and OAuth 2.0 enable a trusted environment for person-to-person resource sharing. Trust is established for the people (Resource Owner and Requesting Party), Clients, and services (Authorization Server and Resource Server). The transactions between UMA 2.0 roles are also trusted as part of the secure solution.
Resource Management
The Resource Owner is empowered to manage (create, update, or remove) their own resources. The owner, authenticated to an Authorization Server, leverages Resource Server interfaces (typically via an application) to manage their resources. The Resource Server is trusted by the Authorization Server as an OAuth 2.0 client.
Owners add a resource to the Authorization Server via the UMA 2.0 registration process. They then add a policy that defines who can access a resource for a specific set of scopes. The Resource Owner can use ForgeRock Access Manager (the Authorization Server) user interface or APIs to manage policies.
Resource Access
The Requesting Party can now access registered resources for which they match a policy. After getting permission from the Resource Server to access a resource, the Requesting Party’s Client contacts the Authorization Server to obtain an access token.
With a valid access token, the Requesting Party or Client can obtain the resource. The Resource Server validates the access token and returns resource information. The returned information may include metadata about the resource and/or external digital content that is associated with the resource.
An organization can use UMA 2.0 to add ForgeRock Secure Sharing functionality to existing services or new person-to-person services. Applications used by the Resource Owner and the Requesting Party can be enhanced to support the secure protocols. The Resource Server functionality can be added to an existing service that does resource management. Alternatively, a Resource Server could act as a front-end to legacy resource management systems.
For more details on implementation, visit the open source Resource Server: https://github.com/ForgeRock/frdp-uma-resource-server.
ForgeRock Access Manager, along with ForgeRock Directory Services, provide turn-key Authorization Server functionality. ForgeRock Identity Management’s Profile and Privacy Management Dashboard is an additional example of an interface to UMA 2.0 AS functionality as part of its single-pane-of-glass consent and permissions management interface.
For Part 1 of this blog series, click here.
For Part 2 of the blog series, click here.
*** This is a Security Bloggers Network syndicated blog from Forgerock Blog authored by Scott Fehrmann. Read the original post at: https://www.forgerock.com/blog/forgerock-secure-sharing-framework
