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.

What that means, in practical terms, is that users and groups won’t have to be synchronized between the Identity Provider (Oracle Identity Cloud Service) and the Service Provider (Weblogic).

This approach presents a great advantage when integrating web applications running in Weblogic with Oracle Identity Cloud Service (IDCS), since we don’t have to worry about keeping IDs in synch, and administrators can concentrate the users/groups management on one single place: IDCS.

1

In the following topics we will demonstrate how to implement such use case, please read on…

Configuration

Configure Weblogic as the Service Provider (SP).

Go to “Security Realms > Providers > Authentication”.

Create a new SAML2IdentityAsserter provider.

2

Go to “Security Realms > Providers > Authentication”.

Create a new SAMLAuthenticator.

3

Reorder the SAMLAuthenticator and SAML2IdentityAsserter. Move them to the top, as shown below.

4

Click on SAMLAuthenticator, and set its control flag to “SUFFICIENT”.

5

Click on the DefaultAuthenticator and set its Control Flag to “OPTIONAL”.

6

Restart all servers in the domain.

Repeat the below steps for each of the managed server hosting the applications that will be federated with IDCS.

Go to Servers > MANAGED_SERVER > Configuration > Federation Services > SAML 2.0 Service Provider.

Enter the following:

Enabled checked
Preferred Binding POST
Default URL* https://HOST:PORT/FederationSampleApp

The default URL is the landing page of the Federated application.

HOST:PORT is the host and port of the managed server running the sample application.

The configuration should look like the picture below.

Click Save.

7

Go to Servers > MANAGED_SERVER > Configuration > Federation Services > SAML 2.0 General.

Fill the information as the picture below.

The field “Published Site URL” must be in the format https://HOST:PORT/saml2.

The field “Entity ID” is the unique identifier of the Service Provider, it will be used later in the IdP configuration.

HOST:PORT is the host and port of the managed server running the sample application.

8

Configure IDCS as Identity Provider (IdP)

Login to IDCS Admin Console.

Go to Applications and click “Add”.

From the list, choose “SAML Application”.

9

Enter the following:

Name Federation Sample Application
Description Sample application to showcase WLS Virtual Users/Groups.
Application URL https://HOST:PORT/FederationSampleApp

HOST:PORT is the host and port of the managed server running the sample application.

For Application URL use the main page on the application deployed in WLS. Click “Next”.

30
In the General panel, enter the following:

Entity ID FederationDomain
Assertion Consumer URL https://HOST:PORT/saml2/sp/acs/post
NameID Format Email address
NameID Format Primary Email

Entity ID must match the value used in the Service Provider configuration.

HOST:PORT is the host and port of the managed server running the sample application.

11

In the Advanced Settings panel, enter the following:

Signed SSO Assertion
Include Signing Certificate in Signature checked
Signature Hashing Algorithm SHA-256
Enable Single Logout checked
Logout Binding POST
Single Logout URL https://HOST:PORT/FederationSampleApp/logout
Logout Response URL https://HOST:PORT/FederationSampleApp

Single Logout URL is the logout URL of the sample application.

HOST:PORT is the host and port of the managed server running the sample application.

12

In the Attribute Configuration section, add one Group Attribute, with the following information:

Name Groups
Format Basic
Condition All Groups

Name must be “Groups” and format must be “Basic” so the SAML Identity Asserter can pick up the groups attributes when the SAML Assertion is posted back to WLS.

13

Click Finish. And Activate.

29

Open the application page, go to “SSO Configuration” tab and click “Download IDCS Metadata” and save the XML file (IDCSMetadata.xml).

15

Assign users to your application in IDCS

Users need to be assigned to applications in the IdP (IDCS) before they can authenticate to those apps.

We do it by assigning individual users to the application in the “Users” tab.

Open the application page and go to “Users” tab.

Click in “Assign Users”.

16

Select the users that should have access to the application.

17

Configure the Identity Provider Partner in WLS

Upload the “IDCSMetadata.xml” file to the <DOMAIN_HOME> folder where the WLS Managed Server is running, for example: “/u01/oracle/domains/FederationDomain”

Login to WLS Admin Console, go to Security Realms > Providers > Authentication and click on the SAML2IdentityAsserter.

18

Go to the Management tab and click “New”, and select “New Web Single Sign-On Identity Provider Partner”.

19

Enter the following information for the IdP Partner:

Name: IDCS-IdP

Choose the IDCSMetadata.xml and click “OK” button.

20

Click on the “IDCS-IdP” partner from the Identity Provider Partners list.

21

Fill in the following information:

Enabled checked
Virtual User checked
Redirect URIs /FederationSampleApp/protected/*
Process Attributes checked

the “Redirect URIs” are all the URIs that should be protected by the SAML SSO policy, that is, every URI that would trigger the SAML SSO flow and/or require authorization.

22

Click “Save”.

this is the key point of this use case, by enabling “Virtual User” and “Process Attributes” we will allow users that are only defined in the IdP (IDCS) to login to our application.

Testing the setup

The sample application (FederationSampleApp) deployment descriptor is configured to allow access to resources under <APP_CONTEXT_PATH>/protected/* to users that belong to “FederationSampleAppMembers” group.

You can modify the deployment descriptor to add the groups you already have created in IDCS or you can create a new group called “FederationSampleAppMembers”.

Web.xml:

<web-resource-collection>

<web-resource-name>ProtectedPages</web-resource-name>

<url-pattern>/protected/*</url-pattern>

</web-resource-collection>

Weblogic.xml:

<security-role-assignment>

<role-name>allowedGroups</role-name>

<principal-name>FederationSampleAppMembers</principal-name>

</security-role-assignment>

To create a new Group in IDCS called “FederationSampleAppMembers”, log in to IDCS admin console and go to Groups. Click Add, and provide the group name.

23

Assign users to the “FederationSampleAppMembers group”. These users will have access to the sample application deployed in Weblogic.

24

Deploy the sample application in your Weblogic and target it to the managed server(s) we configured to Federate with IDCS.

Open a browser and go to https://HOST:PORT/FederationSampleApp/

You should see the sample application main page, which is not protected by any security constraint.

25

If you click in any of the links, the SAML SSO flow is triggered, and you will be redirected to the IdP (IDCS) for authentication.

26

Once you provide your credentials, the IdP (IDCS) will validate them and create a SAMLResponse containing a SAML Assertion that will be posted back to the Service Provider (WLS).

We can inspect the SAMLResponse that was posted to our SP (WLS), by using Chrome Dev Tools.

27

Decoding the SAML Assertion we can see that the interesting pieces are:

The authenticated Subject

<saml:Subject>

<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">paulo.pereira@oracle.com</saml:NameID>

<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">

<saml:SubjectConfirmationData InResponseTo="_0x81d7ccb7b40001c2b13366d827ab79bf" NotOnOrAfter="2017-01-11T23:56:58Z" Recipient="https://HOST:PORT/saml2/sp/acs/post"/>

</saml:SubjectConfirmation>

</saml:Subject>

Assertion Attributes (additional attributes we configured to include group membership).

<saml:Attribute Name="Groups" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">

<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">SalesMembers</saml:AttributeValue>

<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">FederationSampleAppMembers</saml:AttributeValue>

<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">Teste1</saml:AttributeValue>

</saml:Attribute>

If we navigate to the Principals page, in the sample application, we see that Weblogic created the the principals that correspond to our Assertion’s authenticated subject and the groups contained in the Assertion’s additional attributes.

28

The magic here happens because we configured our Identity Asserter (SAML2IdentityAsserter) to use Virtual users and process SAML Attributes. That means the Identity Asserter, when working with a SAML Authenticator (the SAML Authenticator must run with control flag set as “SUFFICIENT” and must be invoked before other authenticators), will create Principals that does not correspond to any user or group in the configured ID store in WLS.

For more information on the SAML Authentication Provider and SAML Identity Asserter, consult the documentation here.

The other key piece of the solution happens on the IDCS side. We configured our application to generate a SAML assertion that includes the user’s groups as additional attributes of the assertion.

That way, we can “propagate” down to WLS the authenticated user and his group membership.

Conclusion

Configuring Federation between IDCS and Weblogic server with virtual users and groups makes it much easier for applications to integrate with IDCS as a single source of Identity administration. The approach discussed here has the advantage of eliminating the user/groups synch between Service Providers (applications) and the IdP (IDCS). Also, legacy applications or new ones that use standard Java Container Security can leverage this use case with minimal changes – if any at all – since the authorization is already defined in the application’s deployment descriptors.

Applications that need to obtain additional user profile information can also be registered with IDCS as OAuth clients and consume IDCS APIs to obtain the logged in user information, but that is material for another blog post…

Comments

  1. Pratik Sharma says:

    Hi Paulo,

    I tried the above steps using a Pool0 IDCS tenant made available to us. The sample app is getting re-directed to IDCS login page. After entering the user details, I am getting the error ‘You are not authorized to access the app. Contact your system administrator’. The user and the group both have access to the Federation Sample Application application in the adminconsole and the application is activated. Please suggest If I am missing anything

Add Your Comment