Multi-Factor Authentication with Oracle Identity Cloud Services – Part II

Introduction The Multi-Factor Authentication part I post described the initial MFA configuration, the enrollment process and second factor authentication with the Mobile Authenticator One-Time Password. In this second post, we will go over the other factors: security questions, notifications, text messages and bypass code – and the additional security constraints for MFA in general. All […]

Multi-Factor Authentication with Oracle Identity Cloud Services

Introduction Oracle Identity Cloud Service (IDCS) has just released version 17.2.2 in May/2017 and with it a cool new feature: Multi-Factor Authentication, or in short, MFA. MFA is a method of authentication that requires the user to present more than one piece of evidence – or factors: one-time pass codes, SMS, security questions, etc – […]

Identity Cloud Services and Weblogic Federation with Virtual Users and Groups

Introduction Federation is a well-known pattern and has been discussed at length on this blog. Almost every vendor or cloud provider out there supports Federation and it’s been around for quite some time now. In this blog post, I will talk about Federation again, but this time in combination with Weblogic’s Virtual Users and Groups. […]

Configuring Oracle Public Cloud to Federate with Microsoft Azure Active Directory

Introduction Companies usually have some Identity and Access Management solution deployed on premises to manage users and roles to secure access to their corporate applications. As business move to the cloud, companies will, most likely, want to leverage the investment already made into such IAM solutions and integrate them with the new SaaS or PaaS applications that […]

Implementing OAuth 2 with Oracle Access Manager OAuth Services (Part V)

Introduction This post is part of a series of posts about OAM’s OAuth implementation. Other posts can be found here: Part I – explains the proposed architecture and how to enable and configure OAM OAuth Services. Part II – describes a Business to Business use-case (2-legged flow); Part III  – deals with the Customer to Business use-case […]

Implementing OAuth 2 with Oracle Access Manager OAuth Services (Part IV)

Introduction This post is part IV of a series of posts about OAM’s OAuth implementation. Other posts can be found here: Part I – explains the proposed architecture and how to enable and configure OAM OAuth Services. Part II – describes a Business to Business use-case (2-legged flow); Part III  – deals with the Customer to Business […]

Implementing OAuth 2 with Oracle Access Manager OAuth Services (Part III)

Introduction This post is part III of a serie of posts about OAM’s OAuth implementation. Other posts can be found here: Part I – explains the proposed architecture and how to enable and configure OAM OAuth Services. Part II – describes a Business to Business use-case (2-legged flow); Part III  – deals with the Customer to Business […]

Implementing OAuth 2 with Oracle Access Manager OAuth Services (Part II)

Introduction This post is part II of a series of posts about OAM’s OAuth implementation. Other posts can be found here: Part I – explains the proposed architecture and how to enable and configure OAM OAuth Services. Part II – describes a Business to Business use-case (2-legged flow); Part III  – deals with the Customer to Business […]

Implementing OAuth 2 with Oracle Access Manager OAuth Services (Part I)

Introduction This post will explain the basics of OAuth 2.0 and how it can be used to protect resources by implementing some of the most common OAuth use cases. OAM provides out of the box OAuth Services, which allows a Client Application to access protected resources that belong to an end-user (that is, the Resource Owner). Before […]

Exposing User System Attributes in OIM 11gR2PS2 GUI Customization

Introduction Recently while working with a customer to help with an upgrade from OIM 11gR1 to 11gR2PS2, one interesting request came up regarding OIM GUI customization. The requirement was to expose some User System Attributes that in R1 were directly available in the GUI customization data but in R2 are not exposed in the GUI […]

Presenting the new IDM Deployment Wizard

Introduction With the recent IDM 11gR2PS2 release Oracle has developed a new deployment tool that aims to automate and reduce the time required to install and configure Oracle Identity and Access Management Components. In this post we are going to present the benefits, supported topologies and components and key points to keep in mind to […]

OIM ICF based connector filter error

Introduction Recently, I was helping a customer in an OIM project go live when we ran an “Active Directory User Target Recon Job” with an AD Connector (11.1.1.6) and a regular expression filter to select just a subset of users. Main Article To our surprise, every time we executed the job, we got a strange […]

Creating a Custom OVD Plugin

1. Introduction In a recent engagement, I worked with a customer that had a business requirement where they needed to create and expose to their application two computed LDAP attributes, based on the value of an existing attribute. For instance, let’s say the original attribute is “myCorpID” and its value could be something like “23451588-IT […]

Part 2: Kerberos Authentication, RBAC and SAML identity propagation in OAG

This post is the second one of a series by Andre Correa and Paulo Pereira on OAG (Oracle API Gateway).

The first post is found at http://fusionsecurity.blogspot.com.br/2013/03/part1-kerberos-authentication-rbac-and.html. Check it out for use case background and the Kerberos authentication part.

As mentioned, one of the requirements in our exercise was to authorize the user against a ROLE X URI matrix, called “Authorization Matrix”. In this post we’re looking at the second policy (Call ‘Perform Authorization’) in the overall flow:

KerberosPolicy

Basically, “Perform Authorization” had to:

a. Obtain the authenticated user (authenticated by Kerberos);

b. Lookup the groups memberships in Active Directory;

c. For the requested URI, query a Database for the authorized roles for that URI in particular;

d. Check if any of the user groups (obtained from AD) is in the list returned by the DB query;

e. Authorize the user in case the check on the previous steps passes.

The OAG Policy we created looks like this:

image

Policy Filters Description

 

1. Process Service Principal Name (script)

This is a script that obtains the authenticated user. Since it is authenticated via Kerberos, the authenticated user id comes in the format of a SPN, <SERVICE>/<USER_ID>@<DOMAIN_NAME>. However, all subsequent steps rely only on the <USER_ID> part of it. Hence, we wrote a script to parse OAG’s attribute “authentication.subject.id”, where it automatically writes an authenticated user id to.

Here’s our script.

image

2. Retrieve User Groups from AD

Here we obtain the authenticated user’s AD groups. To do so, we used the “Retrieve Attributes from Directory Server” filter, who obtains current user’s memberOf attribute from Active Directory.

image

User data are put in OAG’s attribute “attribute.lookup.list”, a HashMap type of data structure. Within the HashMap, OAG keys the user groups values using the retrieved LDAP attribute name, memberOf.

 

3. Process Group DN

This is just another Scripting Language Filter to parse the result from the previous filter and obtain just the group name out of the retrieved DN (Distinguished Names).

image

4. Retrieve Authorized Groups for URI

Here we connect to the Database, and run a SQL query to obtain the authorized groups for the requested URI. We used the “Retrieve Attributes from Database” filter to achieve this.

image

The SQL query to retrieve the authorized roles uses OAG’s attribute “http.request.path” which is automatically created and populated  by OAG with the requested path.

The results of the query are stored in an attribute named after the column names of the SQL query statement, in this case, role_group. OAG adds the prefix “user.” to all attributes populated by the query, resulting in “user.role_group”, used in the next filter in the chain.

image

5. Set Authorization Result (script)

At this point we have two sets of data, the user’s groups from AD and the authorized roles for this particular URI. We just need to check if one of the user’s groups are in the authorized roles set.

OAG has a filter specifically created for Authorization, called Attributes. We couldn’t make it work for the type of comparison we had to make. We also tried the “Compare Attributes” filter, but it is unable to check whether at least one element of a collection is contained in another collection.

Therefore, we wrote another script to loop through one of the sets and do the checking, again another Scripting Language Filter. Note that if the check passes, we set a custom attribute, “user.is.authorized” to true. This attribute is inspected in the next step to decide if user is granted access to the resource.

Obs: We could have simply returned false here and ended the circuit in case the user is not authorized.
image

6. Compare Attribute

The last step is just a boolean evaluation, using the “Compare Attribute” filter. This is a simple filter where we have a few options to compare an attribute to a given value.

image

The result of our authorization policy is a boolean value. If true, we move onto the next step, which is adding a SAML token to the outgoing SOAP message, discussed in the next post of this series. See you there.

Unsolicited login with OAM 11gR2

In a previous post Chris Johnson has discussed unsolicited login with OAM 11g.

In OAM 11gR2 this functionality is supported out of the box and with little effort you can implement Unsolicited Login.
 
 
This post is part of a larger series on Oracle Access Manager 11g called Oracle Access Manager Academy. An index to the entire series with links to each of the separate posts is available.

 

 
 
If you’re interested to authenticate using unsolicited POST, please read on…
 
 

The complete procedure is explained in the official documentation here, but the docs are not clear on some aspects of the configuration.
 
 
To begin with, the documentation states that you have to manually edit the oam-config.xml file, but it does not say where to find it or which one to edit.
 
 
In my lab installation, I found six different oam-config.xml scattered across several folders.
 
After some trial and error I found out that the correct one to edit is OAM_DOMAIN/config/fmwconfig/oam-config.xml
 
Where OAM_DOMAIN is the WLS domain folder for the OAM domain.
 
 
Don’t forget to bounce Admin and Managed Servers after editting the oam-config.xml.
 
Note that in a distributed environment you want to make changes to the file on the admin server and it will then get pushed out to the managed servers after restarts.
 
Now all you have to do is post the login info to the endpoint https://oam_host:oam_port/oam/server/authentication.
 
 
The required information you need to post to the endpoint is:
 
  • username
  • password
  • successurl
     If the authentication succeeds, you will be redirected to the successurl you passed to the endpoint.
 
 
     In case the authentication fails, you will be redirected to the default OAM error page:
 
 
      Now, that isn’t very nice, right?
 
        If you want to get redirected to a custom error page, for instance, to the same login page with the error message displayed in it so you can try to login again, you just need to edit the Authentication Policy for the /oamDirectAuthentication resource (we will talk about this resource further on).
 
 
      To do so, go to Application Domains, IAM Suite, Resources and search for /oamDirectAuthentication.
 
        Open it and edit its Authentication Policy to include the Failure URL to the page you want to be redirected in case of authentication errors.
 
 
 
        If you don’t want to mess with the default Authentication Policy, which is used by other Resources, you can create another Authentication Policy for this resource and make the required changes.
 
        To display the errors messages, check out the docs about creating Custom Error Pages here 
 
        To test the whole thing, you can use a simple JSP to post the info to OAM:
 
 
        And for the JSP of the success URL I print all the request parameters, headers and session attributes:
 
 
         From this point on, you’re already authenticated to OAM and you can access any resources you’re authorized to.
 
        The documentation also describes how you can combine different HTTP operations (POST, GET, DELETE, etc) with different Authentication Schemes (FORM, CERT, etc).
 
        If you have specific requirements for the unsolicited login, you can create/edit the /oamDirectAuthentication Resource of IAM Suite Domain. This resource controls all the specifics of unsolicited authentication, for example, allowing only for HTTP POST and FORM based authentication.
 
        The resource /oamDirectAuthentication is a virtual resource that is defined in the system that represents the physical endpoint for unsolicited login. 
 
        So, when it comes to policy configuration you will always deal with /oamDirectAuthentication, however when it comes to the physical endpoint (the actual servlet URL for posting information) you will use /oam/server/authentication.

 

Converting SSL certificate generated by a 3rd party to an Oracle Wallet

     
     Recently a customer asked me how to import his private key and certificate into an Oracle HTTP Server Wallet.
The customer generated a CSR outside the OHS Wallet Manager, using Open SSL, and sent it to a CA to get his certificates issued by them.
Unfortunately, the Wallet Manager only allows you to import certificates which were created for a CSR generated by the Wallet itself.
Despite this minor limitation, there is a workaround to get your private key, certificate and CA trusted certificates chain into Oracle Wallet.
This post explains the simple steps to achieve this, with a little help from Open SSL.

  1.       What you will need:
a. openssl installed in a machine
b. The server’s certificate (PEM format)
c. The server’s encrypted private key and it’s password
d. The CA root and intermediate certificates (these must be concatenated into a single file, also in PEM format)
 
        2.    On a server with openssl installed, issue the following command:
 

openssl pkcs12 -export -in certfile -inkey keyfile -certfile cacertfile -out ewallet.p12

 

Where:

                certfile: is the server’s certificate
                keyfile: is the server’s private key
                cacertfile: is the CA’s concatenated root and intermediate certificates.
 
Note that the resulting file must be named ewallet.p12 in order to be recognized by Oracle Wallet Manager.

 

 
3      3.       Enter the private key’s passphrase when prompted for it.
        4.       Enter an export password when prompted for it. You MUST supply a non-blank password. You will need to type it again as verification.
        5.       Upload the ewallet.p12 file to the Oracle Application Server. Move it to where the OHS can access it.
        6.       Start the Oracle Wallet Manager application.
        7.      Under the Wallet menu, click Open.
        8.      You will likely receive an error message about the default wallet directory not existing, and asking you if you want to continue. Click Yes.
 
 
       9.   You will be asked to select the directory where the wallet file is located. Find the directory where you moved the file ewallet.p12 to.
      10.   You will be asked for the wallet password. Enter the export password you entered when converting the certificate.
      11.   The wallet should open, and the certificate may be displayed as empty – don’t worry about that right now. You should also see the CA certificate under “Trusted Certificates”.
 
 
      12.   Under the Wallet menu, select “Auto Login”. Verify that it was selected by viewing the Wallet menu again; the Auto Login box should now have a check mark.
 
       13.  Under the Wallet menu, select “Exit” to quit the Oracle Wallet Manager application.
       14.   Now you should have 2 files in the directory: ewallet.p12 and cwallet.sso. Both files must be together at the same directory so the OHS can access the wallet.
       15.   Shutdown OHS.
       16.   Modify your OSH ssl.conf (default location should look something like /home/oracle/Middleware/Oracle_WT1/instances/instance1/config/OHS/ohs1/ssl.conf) so the directive SSLWallet points to the directory where you saved both files, for example:
      
      SSLWallet “${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/${COMPONENT_NAME}/keystores/default
 

 17.   Start OHS and access its HTTPS home page. Inspect the certificate presented by the browser and you should see your new certificate and the CA chain.