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.
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.
Go to “Security Realms > Providers > Authentication”.
Create a new SAMLAuthenticator.
Reorder the SAMLAuthenticator and SAML2IdentityAsserter. Move them to the top, as shown below.
Click on SAMLAuthenticator, and set its control flag to “SUFFICIENT”.
Click on the DefaultAuthenticator and set its Control Flag to “OPTIONAL”.
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.
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.
Configure IDCS as Identity Provider (IdP)
Login to IDCS Admin Console.
Go to Applications and click “Add”.
From the list, choose “SAML Application”.
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”.
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.
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.
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.
Click Finish. And Activate.
Open the application page, go to “SSO Configuration” tab and click “Download IDCS Metadata” and save the XML file (IDCSMetadata.xml).
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”.
Select the users that should have access to the application.
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.
Go to the Management tab and click “New”, and select “New Web Single Sign-On Identity Provider Partner”.
Enter the following information for the IdP Partner:
Name: IDCS-IdP
Choose the IDCSMetadata.xml and click “OK” button.
Click on the “IDCS-IdP” partner from the Identity Provider Partners list.
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.
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.
Assign users to the “FederationSampleAppMembers group”. These users will have access to the sample application deployed in Weblogic.
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.
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.
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.
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.
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…
All content listed on this page is the property of Oracle Corp. Redistribution not allowed without written permission