Wednesday Jan 21, 2015

Scope Grants and Authorization Policies: Diffs

Author: Vadim Lander, Chief Identity Architect, Oracle

In my last post on OAuth, I covered a couple of important considerations regarding granularity of OAuth scopes. My recommendation was to look at scopes not only from the app development perspective, but also consider administrative knowledge and life cycle burden that might be inadvertently created. I discussed that overloading with too many fine-grained scopes will place a burden on the user, creating confusion or complicating policy administration. Its best to define few scopes protecting the high level service, adding few additional scopes to secure access based on minimally required read and write permissions, and only then evaluate if additional scopes are required.

In this blog, I'm going to take a closer look at the difference between a scope grant and authorization policy.

People ask this question all the time - can a client app possessing a token with a given scope access any application resource or only resources authorized by user's consent represented by the granted scope? It turns out people mistake scope grants for security policies designed to protect the application. The answer depends on how people model application's security policies vs modeling scope grants.

Its important to distinguish between a scope grant authorized by a person who happens to be the "Access Approver" for his/her resources and data, and application security policies that govern what a user in session can do within the application. There are two things going on here:

  • First, the application's functional security model must secure the application by utilizing the RBAC and/or ABAC type policies. This typically accommodates role-based, attribute-based, risk-based, context-based, etc. or various combinations. Security Policies ensure application Security Administrators can customize security policies to suit their needs, and Business and/or Security Administrators can authorize users to have functional capabilities.
  • Second, the scope grant must convey the resource owner's approval for application to use the underlying resource. Hence, the scope grant typically represents context to be evaluated by the authorization policy.

For example, the following authorization policy may be protecting access to the Salary attribute when displaying user's detail page in an HR application (expressed in pseudo language):

(Session.User has Role "HR Clerk" or "Self") and (Session.token has UserSalaryScope")

This policy ensures the user must have a role "HR Clerk" and have the end user's approval to see salary data (or be the user who's record is being viewed).

We can see clear delineation between authorization policies that have user-centric context, and scopes that represent user-centric context. The latter is meant to be used in authorization policies, rather than represent the authorization policy itself. This is the way I suggest people work with OAuth scopes for enterprise applications - first define the functional security model represented by authorization policies, then define scopes to be used as context attributes in authorization policies.

Even though its possible to model application's authorization policies to align with scopes 1:1, doing so would be a wrong thing to do, really painting an application into a corner from the security policy and delegation of administration perspectives. Such shortcut would work only for applications with trivial authorization policies or for 100% claims-based applications, but not for enterprise applications with comprehensive policy and administration needs. Sooner or later (usually sooner), scope overuse will manifest itself in inability to adequately administer enterprise application's security.

In the next blog, we will look at other scope-related topics:

  • Scope changes. The Authorization Server is free to grant a different set of scopes than what a client requests. This can happen because of policy, user consent, or just versioning issues.
  • Scope risk. The Authorization Server might issue different tokens with different lifespans based on the scope requested
  • Implicit scopes. Some scopes may be “implicit” where the policy dictates whether user, or a client on user’s behalf is authorized to do something – resulting in “automatic” consent with no actual consent dialo
  • Privileged scopes. The Authorization Server may inject special scopes not requested by clients, by granted non-the less based on the contextual state of the client.

For more information on OAuth please see http://oauth.net/2/

About the Author


Vadim Lander joined Oracle’s Identity & Access Management team in 2009. He advises Oracle on key security technology trends, sets the technical strategy for the IAM Enterprise and Cloud product lines, and works with various Oracle teams on the architecture and implementation of the IAM stack. Previously, Vadim was CTO for the Security BU at CA delivering the architectural blueprints for engineering CA’s next-generation solutions. Vadim joined CA in 2004 with its acquisition of Netegrity, where he was CTO after holding a number of successive growth positions in engineering.Vadim holds a Bachelor of Science degree in Computer Science from Northeastern University in Boston.
Vadim can be reached via LinkedIn

Visit the Oracle Technology Network for more information about Oracle Identity Management Products including downloads, documentation and samples

Engage with us on Twitter @oracleidm and follow us here in the Identity Management blog.

Wednesday Dec 10, 2014

Securing Access with OAuth2: How to deal with OAuth Scopes

Author: Vadim Lander, Chief Identity Architect, Oracle

The OAuth standard has proven itself to be a very effective in managing distributed Web authorization by providing client applications a secure, delegated access to server resources on behalf of a Resource Owner.  A large number of public Internet web sites have standardized on OAuth for service-to-service authorization, the standard has gained traction in securing commercial SaaS/PaaS/IaaS services cloud, and is being adopted by enterprises interested in externalizing internal web services.

Here at Oracle we're using OAuth2 to secure access to Web Services exposed by Oracle Public Cloud services.  While the standard itself is relatively straightforward, there are a couple of areas that each implementation must address on its own. The purpose of this blog is to look at one such area we have to advise application developers on - how to deal with OAuth scopes. We will assume the reader is familiar with the standard OAuth terminology.

Figuring out what scopes to expose is a responsibility of an application developer, and it may be confusing at first:

  • Do I expose a single scope protecting the entire service, or do I expose scopes to protect fine-grained business functionality of my application?
  • Do I break up my service into many smaller services with one scope each, or do I build multi-functional service with multiple fine-grained scopes?
  • How do I balance the needs of my clients to request specific capabilities and the needs of my application owners to manage appropriate policies?

Lets take a closer look at scopes, and see what it means to request scopes that will be granted by the Authorization Server and placed into the Access Token.

An OAuth scope X is an indication by a client that it wants to access the Resource Server to perform X or access something on the service that is related to X. For example, the client may request a claim EMAIL_SERVICE to access the email service, or it may request claim DELETE_INBOX if it desires to delete inbox entries.

The developer of the email service needs to think about what scopes should be exposed in a way that lets services support different types of clients by allowing proper authorization delegation. In the previous example, the “EMAIL_SERVICE” scope is generic and might not be that useful because it grants too much authority. If the email service breaks this into scopes such as “EMAIL_READ”, “EMAIL_POST”, “EMAIL_MOVE”, and “EMAIL_DELETE”, the core functionality of the email service is expressed as scopes. This becomes useful to allow clients to use minimal authority to access the user’s mailbox without requiring full access.

As mentioned previously the purpose of OAuth is to authorize access to a service. Hence some Policy Enforcement Point (PEP) will be tasked with securing access to the Resource Server must be able to determine from the Access Token's authorized scopes whether or not access should be allowed.  Once the token is issued to a client, client's access rights will be bound by scopes encapsulated by the Access Token for as long as the Access Token is valid.

The big question is where to draw the line between defining very granular scopes representing the right to invoke functional "capabilities" exposed by physical service implementations, and creating broad scopes representing the right to invoke the actual physical services.

One important perspective on how to answer this question is to look at the problem from the perspective of the Resource Owner - specifically what authorization decisions need to be made to authorize requested scopes, how often these decisions needs to be made, and what needs to be known in order to make such decisions.  The lifecycle of managing such authorization decisions should be straightforward – otherwise the policies will be incomplete, out of date, or overly permissive.

From the Resource Owner perspective there are two important considerations:

  • Who owns the data - end user or the target service
  • Who gets to specify the authorization policy - end user or application owner

The difference in considerations is important since it determines who gets to authorize the client's request for specific scopes  - end user who's data will be requested by the client, or the business/security admin configuring the client and granting it specific privileges.  Lets take a close look at each consideration:

End users authorizing request for scopes

If the Resource Server is tasked with providing access to end user's data (such as the case with consumer sites or user-centric apps such as email), the end user is the ultimate authorization authority for deciding whether or not requested scopes should be granted. 

In this case the purpose of a scope is to let the end user know what the client is trying to do with end user's data (ex: Requesting access to one's pictures or emails, requesting access to one's mobile GPS data, etc.). Then when the Access Token is granted, the approved scopes are "burned" into the token. Presenting this Access Token to the Resource Server conveys the fact the end user has approved client application's request to access his/her data. 

We can see that scopes represent client's intent to access user's data, and can be modeled based on the number of user's data categories the Resource Server wants to protect from "super user" access.

This requirement to secure access to end-user's data is the primary reason for the 3-legged OAuth interaction where the end user (data owner) is responsible for providing consent to operations requested by the client.  Here, the end user is familiar with, and wants to protect access to his/her data, so modeling scopes based on user's data categories (or collection of categories) makes sense. This model is often used by user-centric cloud services such as mail, photos, storage, documents, etc.

Business admins authorizing request for scopes:

There are numerous commercial/enterprise services where the Resource Server is consumed not by the end user directly, but by partners who build clients to consume, expose, or extend application functionality. 

In this case the purpose of scopes is to represent authorization permissions as granted by an administrative process responsible for registering clients.  For example, a real estate site is exposing listings, where unpaid clients have access to listings without addresses, while paid clients have access to addresses. Here, “Address” would be a scope, and it would be the service administrator configuring clients and granting them allowed scopes based on the level of service a client has paid for.

We can see that scopes represent fine-grained capabilities the Resource Server is charging for, using administrators (or automated sign up processes) to decide the authorization policy.

Looking at both scenarios, we can conclude that having too many scopes will create a burden on some user to try and understand/manage the meaning of scopes.

In the case of user-centric scopes, the end user is expected to understand the meaning of the data managed on his behalf.

In the case of business admins, they're expected to understand business rules (or in the case of automated client registration, have the ability to collect required service-level agreements).

The more scopes are exposed by a Resource Server, the greater the burden on a user (end user or administrator) to understand the exact meaning.

Hence, the overarching goal of application developers is to make their users capable of understanding the underlying authorization process, and this requires looking at scopes not only from the application development perspective but also from "administrative" knowledge and life cycle burden a developer might inadvertently create - some human being will have to be responsible for and trained in understanding the meaning of scopes.

Ultimately, the application developer has to think about what scope means in the context of “their” application, including how much delegation (to an end user or policy) should be exposed. There will be as many scopes as the developer wants to expose to a user who is expected to understand their meaning – this could be an end user of social/mobile app clients accessing his/her data, or a security policy admin for enterprise/commercial applications.

Overloading with too many fine-grained scopes will place a burden on the user, creating confusion or complicating policy administration. Its best to define few scopes protecting the high level service, adding few additional scopes to secure access based on read/write operations, and only then take a closer look at whether or not any additional scopes are required.

This is it for the first installment on OAuth scopes.  In the next blog, we will look at other scope-related topics:

  • Scope affinity. Can a client with a given scope access any resource or only the resource associated with the authorizing (and/or owning) user?
  • Scope changes. The Authorization Server is free to grant a different set of scopes than what a client requests. This can happen because of policy, user consent, or just versioning issues.
  • Scope risk. The Authorization Server might issue different tokens with different lifespans based on the scope requested.
  • Implicit scopes. Some scopes may be “implicit” where the policy dictates whether user, or a client on user’s behalf is authorized to do something – resulting in “automatic” consent with no actual consent dialog.
  • Privileged scopes. The Authorization Server may inject special scopes not requested by clients, by granted non-the less based on the contextual state of the client.

For more information on OAuth please see http://oauth.net/2/

About the Author


Vadim Lander joined Oracle’s Identity & Access Management team in 2009. He advises Oracle on key security technology trends, sets the technical strategy for the IAM Enterprise and Cloud product lines, and works with various Oracle teams on the architecture and implementation of the IAM stack. Previously, Vadim was CTO for the Security BU at CA delivering the architectural blueprints for engineering CA’s next-generation solutions. Vadim joined CA in 2004 with its acquisition of Netegrity, where he was CTO after holding a number of successive growth positions in engineering.Vadim holds a Bachelor of Science degree in Computer Science from Northeastern University in Boston.
Vadim can be reached via LinkedIn

Visit the Oracle Technology Network for more information about Oracle Identity Management Products including downloads, documentation and samples

Engage with us on Twitter @oracleidm and follow us here in the Identity Management blog.

Wednesday Oct 30, 2013

Registration Open Now! Virtual Developer Day: Oracle ADF Development

Is your organization looking at developing Web or Mobile application based upon the Oracle platform?  Oracle is offering a virtual event for Developer Leads, Managers and Architects to learn more about developing Web, Mobile and beyond based on Oracle applications. This event will provide sessions that range from introductory to deep dive covering Oracle's strategic framework for developing multi-channel enterprise applications for the Oracle platforms. Multiple tracks cover every interest and every level and include live online Q&A chats with Oracle's technical staff.  

For Registration and Information, please follow the link HERE

Sign up for one of the following events below

Americas - Tuesday - November 19th / 9am to 1pm PDT / 12pm to 4pm EDT / 1pm to 5pm BRT

APAC - Thursday - November 21st / 10am - 1:30pm IST (India) / 12:30pm - 4pm SGT (Singapore) / 3:30pm -7pm AESDT

EMEA - Tuesday - November 26th / 9am - 1pm GMT / 1pm - 5pm GST / 2:30pm -6:30pm IST


About

Oracle Identity Management is a complete and integrated next-generation identity management platform that provides breakthrough scalability; enables organizations to achieve rapid compliance with regulatory mandates; secures sensitive applications and data regardless of whether they are hosted on-premise or in a cloud; and reduces operational costs. Oracle Identity Management enables secure user access to resources anytime on any device.

Search

Archives
« August 2015
SunMonTueWedThuFriSat
      
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
     
Today