Background:
Oracle Identity Federation is set up and configured as an Identity Provider. One of the client’s partners would like for the assertion to include two (2) attributes that do not exist in the IDP’s user data store. To include these attributes in the assertion we will use Oracle’s Custom Action Framework. (Documented in 11.1.1.4)
Set up the WLST Environment:
The syntax to set up the environment on Linux systems is:
>bash
>export $DOMAIN_HOME=PATH_TO_DOMAIN_HOME
[e.g. export DOMAIN_HOME=/apps/oracle/Middleware/user_projects/domains/IDMDomain/]
>source $ORACLE_HOME/fed/scripts/setOIFEnv.sh
(replace $ORACLE_HOME with the correct path for your environment.)
[e.g. source /apps/oracle/Middleware/Oracle_IDM1/fed/scripts/setOIFEnv.sh]
Executing the Commands
Execute the following command to enter the WLST script environment for Oracle
>java weblogic.WLST
This will run some code and then leave you at a wls command prompt (e.g. wls:/offline)
Next, you will need to connect to the WLS server where you will deploy the JSP.
wls:/offline>connect(‘weblogic’,’password’,’t3://idp.acme.com:7499′)
Connecting to t3://idp.acme.com:7001 with userid weblogic …
Successfully connected to Admin Server ‘AdminServer’ that belongs to domain ‘IDMDomain’.Warning: An insecure protocol was used to connect to the
server. To ensure on-the-wire security, the SSL port or
Admin port should be used instead
Note: in this instance you can ignore the SSL security warning.
To execute a command, use the format:
command-name(‘param1′,’param2’,…)
Execute the following (2) setConfigProperty commands.
[the following was provided by Oracle Corporation]
Oracle Identity Federation Configuration
- Enter the WLS scripting environment for the OIF instance.
- Set the authncontext property containing the root context of the post-processing plugin page
setConfigProperty('serverconfig','authnpath','/bridge.jsp','string')
- Set the authnpath property containing the relative path of the post-processing plugin page:
setConfigProperty('serverconfig','authncontext','/bridge','string')
- Exit the WLST script environment
Configure OIF assertion attribute mapping :
1. In the EM console “Federations” page, select the entry corresponding to a
service provider to which the attribute is to be sent, and click “Edit”.
Note: This must be done for each service provider that needs to receive
the attribute.
2. Click the “Edit” button next to “Attribute Mappings and Filters”.
3. In the “Name Mappings” tab, click “Add”.
4. In the “Add Attribute Name Mapping” window, set the value of both
“User Attribute Name” and “Assertion Attribute Name” to “specVer”, and
check the “get Value from User Session” and “Send with SSO Assertion”
options. Click “OK”.
Note: The sample JSP sets the attribute name “specVer” in the user session.
OIF can be configured to map “specVer” to any attribute name in the
outgoing assertion.
5. In the “Attribute Mappings and Filters” page, click “OK”.
6. Check the “Enable Attributes in Single Sign-On (SSO)” option, and check the
NameID format for which you want to send assertion attributes.
7. Click “Apply” to save the changes.
8. You can use WLST commands, to change the mapped assertion attribute name to
another desired value, for example:
addFederationMapEntryInMap(‘<spProviderID>’,’attributelist’,’specVer’,
‘assertion-attr’,’ca:gc:cyber-authentication:basic:specVer’,’string’)
Note: Using the WLST commands is sometimes needed to work around a bug in
the 11gR1 EM console that does not correctly handle attribute names
containing certain characters, including the ‘:’ (colon) character.
Modifying the sample application :
To modify the attributes placed into the user session, modify the bridge.jsp
file in the /bridge/web directory.
To change the application name and/or context, modify the application.xml and
the web.xml file in the /bridge/descriptors directory.
After modifying the application JSP or descriptor files, you must rebuild the
application by invoking the Ant build script from the /bridge directory:
ant build
The resulting bridge.ear file is written to the /bridge/build/ear directory.
Implementation of bridge.jsp:
The JSP looks like this:
<%@page buffer="5" autoFlush="true" session="false"%>
<%@page language="java" import="java.util.*"%>
<% ///////////////////////////////////////////////////////////////////////// // This sample JSP sets an attribute in the OIF user session, by // acting as a bridge in the OIF authentication engine flow. // // Copyright (C) 2010, Oracle and/or its affiliates. All rights reserved. /////////////////////////////////////////////////////////////////////////
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");
response.setHeader("Expires", "Thu, 29 Oct 1969 17:04:19 GMT");
// This JSP page receives a request from an OIF authentication engine,// adds an attribute to the map stored in the request obect for the user session,
// and forwards the request back to OIF to resume the authentication flow.
// Retrieve any exiting attribute map from the request.
Map attributes = (Map)request.getAttribute("oracle.security.fed.authn.attributes");
// Create the attribute map if none exists yet.
if (attributes == null) attributes = new HashMap();
// Add specVer={"1.0"} to attribute map.
Set values = new HashSet();
Set values1 = new HashSet();
values.add("1");
values1.add("0");
attributes.put("application", values);
attributes.put("siteid", values1);
// Set the attribute map in the request.
request.setAttribute("oracle.security.fed.authn.attributes", attributes);
// Forward the user request back to OIF.
request.getSession().getServletContext().getContext("/fed").getRequestDispatcher("/user/loginsso").forward(request, response);
%>
This code is also available
here in the file bridge.jsp.
References:
Brad Tumy 