OAuth2 security in Cloud

In my previous blog i explained about OAuth2 protocol. In this blog i will explain how you can use Oracle OAuth2 support (provided in 11gPS6 patch set and PS7 release) to secure your applications that are deployed on-premise or cloud.
I will be explaining 2- legged OAuth2 flow using client credentials grant

Use case

SaaS App (SOA App) - > REST service.

The above picture presents a high level overview of a SaaS app calling REST service. The SaaS app could be any Multi tenant cloud enabled app e.g. CRM/ ERP available over cloud. The SaaS app internally may be using BPEL process. In this example the SaaS app is deployed as a Oracle SOA composite app

In order to leverage OWSM OAuth2 security feature you need to have Oracle Access Manager (OAM) installed in your env which provides OAuth2 services. 

Token flow

The following picture shows the token flow b/w OAuth2 sever client app and service.
The client and Service app are secured with OWSM Agent OAuth2 security policies.

1) OWSM Client Agent sends request for OAuth2 AT (JWT) by sending authorization grant using standard OAuth2 flows. The authorization request is signed using OWSM client’s Private Key.
2) OAuth2 Service verifies OWSM Client request and responds with a signed Access Token (JWT).
3) OWSM client propagates this AT to Service secured with OWSM Service Agent.
4) OWSM Service agent verifies the AT and responds with a valid response or errors out in case AT does not verify.

We will be doing following.

1) Enabling OAM OAuth2 Service
2) Configuring OAuth2 Service
3) Registering your app with OAM OAuth2 service
4) Requesting token using client credentials grant - Basic Auth
5) Securing Service App (RESTful Service) with OWSM OAuth2 Security policies
6) Securing Client app (SOA) with OWSM OAuth2 Security policies
7) Establishing trust
8) Deploying and Test your apps.

1) Enable OAM OAuth2 Service

1.1) Login to OAM console.

This assumes that you have already installed and configured Oracle Access Manager server, For details on installing and configuring Oracle IDM product suite you can refer to this blog post


















1.2) Oracle Access Management 11.1.2.3 introduces a redesigned Oracle Access Management Console. This new Console displays a Launch Pad and subsequent pages based on the Administration Role to which a user is assigned a successful login.




1.3) Click on Mobile Security - > Mobile OAuth Services

1.4) The console will show the list of Services , Enable - Mobile and Social. This should OAuth2 service. A green check mark in the Status field beside the service name indicates the service is enabled. A red circle with a cross through it indicates that the corresponding service is disabled.

2) Configure OAM OAuth2 Service 

2.1) Under OAM Console -> Mobile Security - > Mobile OAuth Services

2.2) You can either create a new Identity domain or use the out of box Default domain.



2.3) Default domain -> Service Profiles -> OAuthServiceProfile


2.4) This shows the default token settings which you can configure e.g.token expiry for various authz grants.

2.5) You can also configure the trusted issuers. Please check the URL of OAuth2 service Endpoint which client will use for sending Access Token request.

3) Register your application

3.1) Default domain-> Clients - > OAuth Web client - > Create 

3.2) Register you client. Provide name and description. OAM OAuth server generates a random unique client id and client secret for the client. Once can choose to provide user defined value.
For e.g.
Client ID - mycustomId
Client Secret - v1rCJvxbtMKeaiDduk



3.3) Ensure the required Grant types are selected. You can also configure Scope. Using allow access to all scope option for this use case.

4) Requesting token using client credentials grant - Basic Auth

You can use the following curl command to get AT from OAuth2 server -

curl -i -H 'Authorization: Basic bXljdXN0b21JZDp2MXJDSnZ4YnRNS2VhaURkdWs=' -H 'ContentType: x-www-form-urlencoded'  --request POST 'http://slc06uwa.us.oracle.com:14100/ms_oauth/oauth2/endpoints/oauthservice/tokens' -d 'grant_type=client_credentials'

This should
Here client ID and Client Secret are passed in base64 encoded format as part of Authorization header.

OAuth2 Server token endpoint - >
http://slc06uwa.us.oracle.com:14100/ms_oauth/oauth2/endpoints/oauthservice/tokens

You can use any tool to encode client credentials registered with OAuth2 server in step 3.2 in following format - ClientId:ClientSecret.

The OAuth2 server should respond with an Access Token which is a JWT e.g. -

HTTP/1.1 200 OK Date: Wed, 05 Aug 2015 16:04:52 GMT Content-Type: application/json {"oracle_client_assertion_type":"urn:ietf:params:oauth:client-assertion-type:jwt-bearer","expires_in":604800,"token_type":"Bearer","oracle_tk_context": "client_assertion","access_token":"eyJhbGcidHp[…..]zzi4BCjHY"}

Now let's see how to use OWSM Oauth2 securit policies with your client and service apps,

5) Secure REST Service using OWSM OAuth2 security policy.

Policy	Description
oracle/ multi_token_rest_service_policy	This policy verifies the Access Token sent from client app.

Attach oracle/multi_token_rest_service_policy by updating web.xml file of REST application

The following provides an example of how to update the web.xml file. 

<?xml version = '1.0' encoding = 'windows-1252'?> <web-app xmlns="http://java.sun.com/xml/ns/javaee"          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"          xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"          version="2.5">   <servlet>      <servlet-name>helloworld</servlet-name>      <servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>      <load-on-startup>1</load-on-startup>   </servlet>   <servlet-mapping>         <servlet-name>helloworld</servlet-name>         <url-pattern>/restservice/*</url-pattern>   </servlet-mapping> <!--OWSM Security Filter entry-->   <filter-mapping>     <filter-name>OWSMSecurityFilter</filter-name>     <servlet-name>helloworld</servlet-name>   </filter-mapping>  <filter>     <filter-name>OWSMSecurityFilter</filter-name>     <filter-class>oracle.wsm.agent.handler.servlet.SecurityFilter</filter-class>     <init-param>       <param-name>servlet-name</param-name>       <param-value>helloworld</param-value>     </init-param>     <init-param>       <param-name>oracle.wsm.metadata.policySet</param-name>       <param-value><![CDATA[<sca11:policySet name="policySet" appliesTo="REST-Resource()" attachTo="Service('*')"                             xmlns:sca11="http://docs.oasis-open.org/ns/opencsa/sca/200903"                 xmlns:orawsp="http://schemas.oracle.com/ws/2006/01/policy"                 xmlns:wsp15="http://www.w3.org/ns/ws-policy">                     <wsp15:PolicyReference URI="oracle/multi_token_rest_service_policy" orawsp:category="security" orawsp:status="enabled">                     </wsp15:PolicyReference>                 </sca11:policySet>]]>             </param-value>      </init-param>   </filter> </web-app>

You can also use GPA feature (beyond the scope of this blog) to secure your REST services.

6) Secure Client (SOA app) using OWSM OAuth2 Security

You can secure your SOA app at design time using J developer.

4.1) Secure SOA Reference WS Binding (client) - Right click - > Configure SOA WS Policies

 4.2) Select OWSM OAuth2 client policies



4.3) Click on Edit config override property for oauth2_config_client_policy

4.4) Override token.uri to OAuth2 server endpoint

Here token.uri must point to the OAuth2 server endpoint URL. In this example endpoint URL is http://slc06uwa.us.oracle.com:14100/ms_oauth/oauth2/endpoints/oauthservice/tokens


4.5)Edit config override for http_oauth2_token_client_policy if you wish to override default configuration.I will use the default.

5) Establish Trust 

In above flow there are 3 main components involved.

1) OAM OAuth2 server

2) SaaS app

3) REST sevice 

5.1) Trust between OAuth2 server and client

In order to verify the OWSM client (signed) request for Access Token OAuth2 service should have the public key certificate corresponding to the private key used to sign the request in its keystore.

OAuth2 server responds with a signed access token

5.2) Trust between OAuth2 server and Service

The service must also trust the Access Token (signed) sent from OAuth2 server.To set up trust between OAuth2 server and service import the OAuth2 server signing certificate into resource server keystore. 

6) Deploy and Test your apps.

That's it you can now deploy and Test your apps.

I have tried to touch upon the high level steps and configuration you require to use OAuth2 security. There are a number of fine level security configuration which you can configure like setting trusted issuers, setting scope, switching identity, setting up SSL etc just to name a few.

OAuth2 security

I have been getting multiple calls/emails related to leveraging OAuth2 security feature within Oracle Fusion Middleware so decided to write a blog on it. This blog provides an overview on OAuth2.0

Here is the definition from OAuth2.0 spec.

"The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf."

In simpler terms

"OAuth2 enables applications to access each others data without sharing passwords"

OAuth2 uses the concept of delegated authentication and Access token (typically JWT token) to achieve this. Many services such as Facebook, Github, Twitter and Google already provides Oauth2 implementations. Here is a list from Wikipedia. Let me explain this with a simple use case.

Use case: You want to print your photos posted on Facebook. There is a photo printing app (third party / client app) which provides this service.

• You want to ensure that the printing application only gets access to your photos but not to other operations like posting on your wall, access to your friend and there photos. 
• You don't want to share your Facebook password with client app. 
• You don't want to sign up with the client app.
• You want to ensure that the printing app gets access to your resources for a limited time period and after that you wan't to revoke its access.

Let's see how its implemented using OAuth2. The client app (printing app) which intends to access user resources provides an option on there home page to login via Authorization Server. In this scenario Facebook server acts as the Authorization server

Once you click on "Login with Facebook" you are redirected to authenticate with your facebook credentials.

After login you are presented with an authorization window asking for your permission whether to allow the app or not to access your information and act on your behalf. You choose what all information the client app can access.

Once you click okay you are redirected back to the app. Once the app is authorized it can get an access token from Facebook which can be used to access your resources. In this case the app do not handles authentication but delegates it to Facebook (authorization server). From client app perspective they can get access to user's resources and from user's perspective they get a smoother experience.Users are saved from creating login with every new app and the pain of creating password and remembering them. Also if at a later point of time you wish to revoke access of client app you can do this by logging into Facebook/Authorization server and remove the access of app.
Now let's try to map the above example with OAuth2.0 flow defined in spec.

OAuth2.0 defines four roles:
1) Resource Owner - the User user who authorizes an application to access their account. The application's access to the user's account is limited to the "scope" of the authorization granted
2) Client - the application that wants to access the user's account.
3) Resource Server - hosts the protected user accounts
4) Authorization Server - verifies the identity of the user then issues access tokens to the application. Can be same as Resource server, as in above example

A - The application (client) requests authorization to access service resources from the user (Resource Owner)
B - If the user authorized the request, the application receives an authorization grant
C - The application (client) requests an access token from the authorization server (API) by presenting authentication of its own identity, and the authorization grant
D - If the application identity is authenticated and the authorization grant is valid, the authorization server issues an access token to the application. Authorization is complete.
E - The application requests the resource from the resource server (API) and presents the access token for authentication
F - If the access token is valid, the resource server (API) serves the resource to the application

This is the most common OAuth2 flow: the authorization code flow or 3-legged flow. OAuth2 provides other flows which work for slightly different scenarios

• Authorization Code: used with server-side Applications
• Implicit: used with Mobile Apps or Web Applications (applications that run on the user's device)
• Resource Owner Password Credentials: used with trusted Applications, such as those owned by the service itself
• Client Credentials: used with Applications API access, this grant type is used when the app is also the resource owner. An end user does not participate in this grant type flow. 

That's all for now, in my next blogs i will explain How to use Oracle OAuth2 support (provided in 11gPS6MLR and PS7) release to secure your apps and how its different from other SSO solution like SAML, OpenID 

Securing your SOA

In this blog i will explain how Oracle SOA suite addresses the security requirements of SOA application. The following shows the typical workflow of an order processing application.The application is built using Oracle SOA suite.

The SOA app shows the interaction between customer and order processing application. Once customer places an order it need to be validated and processed.


In addition the order processing app may integrate with shipping providers to ship the order.

Security challenges 
When a customer places an order at a retailer's Website, it is readily apparent that the order transaction must be secure. However, there is more to it than meets the eye. The retailer's order fulfillment applications involve interactions with inventory management systems. Once the order is ready to be shipped, the retailer interacts with a shipping trading partner, and the customer should be provided with services to monitor the order's status. Each of these interactions would need security implementation at the application layers and, generally, the transport protocol layer as well. Moreover, organizations must set up and manage various policies: Who owns the data? Who is responsible for its veracity? How do departments and trading partners share their data?

These interactions bring up requirements similar to a customer placing an order on a Website. Security must be enforced in several layers during the message exchanges between these two trading partners, and policies must be established to govern the services.

Exposed applications and services become vulnerable to attacks, and the greater the number of integration and endpoints, the greater the number of potential points of attack. Moreover, with communication between services and consumers, ensuring secure operations over trust boundaries is crucial. Without an SOA security model in place, the entire business ecosystem is at risk.
The security requirements common to these scenarios include:

• Authentication: How do I know your identity is true?
• Authorization: Are you allowed to perform this transaction?
• Integrity: Is the data you sent the same as the data I received?
• Signature: Create and verify an electronic signature analogous to a handwritten signature.
• Confidentiality: Are we sure that nobody read the data you sent me?
• Auditing: Record all transactions for verification after the fact.
• Nonrepudiation: Both sender and receiver can legally prove to a third party (e.g., a judge) that the same data was sent and received in a transaction.

Securing your SOA using Policies

Oracle SOA suite comes up with number of out of box security policies. In addition to the security policies there are number of policies related to reliability, addressing, mtom and logging.

Following Table describes the supported policy categories.  

Category	Description
Security	Implements the WS-Security 1.0 and 1.1 standards. They enforce authentication and authorization of users. identity propagation, and message protection (message integrity and message confidentiality).
Addressing	Verifies that simple object access protocol (SOAP) messages include WS-Addressing headers in conformance with the WS-Addressing specification. Transport-level data is included in the XML message rather than relying on the network-level transport to convey this information.
Reliability	Supports the WS-Reliable Messaging protocol. This guarantees the end-to-end delivery of messages.
MTOM	Ensures that attachments are in MTOM format. This format enables binary data to be sent to and from web services. This reduces the transmission size on the wire.
Management	Logs request, response, and fault messages to a message log. Management policies can also include custom policies.

Also within each category there are sub categories and there are number of policies within each sub-category. For example security category have authentication, authorization, message protection as subcategories.

You can secure your SOA app at design time or post deployment by attaching these Policies.
1) Design time policy attachment using Oracle Jdeveloper.
While creating your SOA app using Oracle Jdeveoper, you can choose to secure your SOA.








2) Post deployment policy attachment using Oracle Fusion Middleware Enterprise Manager (EM) console.


That’s all for now..

Identity and Access Management

Let's try to analyze what Identity and Access Management (Idm/Idam/IAM) is all about, why would organization care for it and the benefits it offers.

What is Identity and Access Management-
Identity and Access Management deals with managing the identity and access of an entity. The entity could be individual user or an application which interacts with a system/organization.The following figure shows the main components of the Identity and Access Management Framework.

There are several technologies and security standards which are used to implement Idm like - SSO, SAML, WS-Federation, JWT, STS, OAuth, OpenID, Directory services, WS-Trust, WS-Security just to list a few. Instead of going into details of each of them let's understand the basic concepts which forms the basis of Identity and access management

• Authentication  - who you are
• Authorization/Access control - what you are authorized to do
• Single Sign on - login once
• Role Based identity - users can be grouped together based on role e.g admin, HR roles
• directory - users repository
• Provisioning - The process of creating identities, defining their access privileges and adding them to an ID repository/directory.
• de-provisioning - The process of removing an identity from an ID repository and terminating access privileges.
• identity life cycle - managing user identity flow -  Provisioning (when users joins the system), maintaining access (as they interact with system) and de-provisiong (once they leaves the system)
• Federated Identity - sharing identity across systems and enterprise boundaries.

Need for Identity and Access Management 

Before going into details of how identity management systems works let's analyze the need for it. Here is a very simple example.

The following picture shows services offered by an enterprise/organization e.g HR apps, Supply chain management apps and ERP apps. These apps are accessed by users/partners/contractors. When a user wish to access an app she authenticates using her credentials (username/password), the app than validates the credentials and allow/disallow access to the app and its resources. Also the apps are accessible to specific users who belongs to that role. Human Resources guys should access HR apps Sales guys should be allowed to access Sales App and so on. If a user have access to different app she need to create login with each app, have to remember password for each of them. This gets too complicated when the number of users and apps/services increases. 

With the evolution of web 2.0 and cloud identity management the situation doesn't get any better, the number of logins and passwords that employees must use on a daily basis has escalated and is a growing source of frustration and lost productivity. Worst of all, there’s the temptation to use the same password for all applications or to write down SaaS passwords on a sticky note, creating security risks that most organizations are trying to avoid.

In addition to the core services the app provides it also has to manage additional functions related to user management and access management.

Simplified Solution with Identity and Access Management system in place

• Identity and Access Management pushed to IDAM system
• Login Once - smoother login experience, no need to remember multiple passwords, 
• Token based access - applications don't have to manage user authentication but rely on security tokens offered by Access management component to check user authn and authz
• Identity life cycle management - deals with managing user identity flow -  Provisioning (when users joins the system), maintaining access (as they interact with system) and de-provisiong (once they leaves the system)

How Identity and Access Management systems works

A typical ID management system today comprises four basic elements: a directory of the personal data the system uses to define individual users (think of it as an ID repository); a set of tools for adding, modifying and deleting that data (the access life cycle management stuff); a system that regulates user access (enforcement of security policies and access privileges); and an auditing and reporting system (so you'll have a way to verify what's actually been happening on your system).

Identity Life cycle