Month: April 2011

Federal #ICAM “Reading List” #IDM #Identity

I have had a number of conversations over the last few weeks regarding ICAM, which is the U.S. Government’s Identity, Credentialing, and Access Management initiative. Essentially, these are a set of guidelines, frameworks and specifications to assist Federal agencies in implementing Identity and Access Management. I have had my own library that I often refer to and I thought it would be good to share these links here:

claims-based authorizations conversation

I was following a conversation on Twitter about claims-based authorizations … the guys having the conversation brought up some pretty good points and I thought it would be great to have a copy of this conversation.  Feel free to correct any mistakes I may have made in my notes.  I’d like to eventually follow up with Nishant and get more information on his last tweet about the RP not needing to know the decision context.  I generally agree with the statement but I am wondering about the use cases where the RP does want/need to know about the decision context.  … maybe you guys @nishantK, @paulmadsen, or @indpendentid could add some examples of what a “decision context” would or coud look like. 


Is it within a PDPs job description to respond to queries of the form ‘I intend to do X at Y. That OK?’ with a signed ‘You can do X at Y’

4/7/11 1:40 PM


@paulmadsen You’ve essentially described a subject-bound capability. You can do this as a bearer token too; “the bearer can do X at Y”

4/7/11 1:47 PM


@bobblakley @paulmadsen (and to answer your actual question: it depends. On the PDP’s interface and semantic description)

4/7/11 1:50 PM


@bobblakley thanks Bob, that’s what I expected. So PDP not necessarily constrained to y/n answers

4/7/11 2:02 PM


@paulmadsen Pre-use decisions carry the same issues as claims-based attributes. Tendency towards more information in case of need>gtr costs

4/7/11 2:17 PM


@independentid you seem to be interpreting ‘claims- based’ more narrowly than I, ie that they necessarily imply capabilities/pre-use authz?

4/7/11 2:27 PM


@paulmadsen But that’s the model that is needed to deliver on the promise of claims-based authorization, isn’t it? /cc @independentid

4/7/11 2:52 PM


@NishantK I think a claim can carry (as per Hal) either a property or a capability – the latter implies the issuer does some ‘pre-authz’

4/7/11 2:56 PM


@paulmadsen Agreed. But to @independentid’s point, both cases precede actual use, and force sender of claim to “plan” for all possibilities

4/7/11 3:28 PM


@NishantK @paulmadsen How does sender know what decisions will be needed? Discovery – securityconstaint? Can decider decide without context?

4/7/11 3:32 PM


@NishantK but with the property model, the issuer doesnt need to know the particulars of the subsequent use – like a passport

4/7/11 3:32 PM


@independentid agreed. Capabilities model implies resource info made available to PAP

4/7/11 3:36 PM


@paulmadsen Kind of like the “visa”s we use to have meetings in the US? The analogy that advance decisions are like passport visas.

4/7/11 3:36 PM


@independentid who issued the visa – Canada or the US? 🙂

4/7/11 3:41 PM


@paulmadsen Well, I believe since you are in Canada, the PDP is US. I know its confusing, since your US PDP is actually in Ottawa

4/7/11 3:43 PM


@independentid its an exit visa Im thinking of, ie Canada saying Im allowed to leave

4/7/11 3:49 PM


@paulmadsen Yes, property model means issuer doesn’t need to know, but also can’t know if it wants to (which is a real issue for enterprise)

4/7/11 4:28 PM


@paulmadsen Also externalizing authZ is about RP not needing to know decision context (something they’re often bad at), leaving it to Issuer

4/7/11 4:41 PM


Additional comments made:  The conversation continued after I had left work … and then picked up briefly this morning.  I wanted to add the additional comments so that the entire thread was captured.
I agree with Steve and would like to see a collection of use cases that focus on externalized authorization.  @paulmadsen suggested that @ggebel was the go to source for such use cases.  I know that he has been blogging about these here (
@brad_tumy I think @nishantk was right on about RP not needing to know decision context… I feel it is a core tenant of externalizing autZ
4/7/11 5:41 PM
@brad_tumy @nishantk I think it is a separation of duties issue… if info is to be shared with the RP, should be by the issuer not the PDP
4/7/11 5:45 PM
RT @brad_tumy @benatnovell @nishantk agree they don’t “need” to know most cases … is there a case where would need to know? < Audit?
4/7/11 5:47 PM
@paulmadsen @brad_tumy CCW as in COM Callable Wrapper? Too tech for me 😉 I just say context usually clear to RP so design claims to match
4/7/11 5:50 PM
@paulmadsen So you’re saying that “Because he told me to” won’t hold up under auditors stern (but loving) gaze? @brad_tumy @benatnovell
4/7/11 6:01 PM
@brad_tumy @benatnovell Usually done for regulatory CYA. But sometimes it’s needed because of specifics in contract SLAs
4/7/11 6:02 PM
@brad_tumy @benatnovell In any case, most RPs don’t know anyway. Role acts as proxy for context. RP usually doesn’t know why user has role
4/7/11 6:05 PM
@paulmadsen @benatnovell @brad_tumy @NishantK What’s a good catalog of externalised authz use cases? Issuer != PDP seems so academic to me
4/7/11 6:51 PM
@paulmadsen @benatnovell @brad_tumy @NishantK That was genuine request for catalog of extern’ed authz use cases please. I need enlightening
4/7/11 9:38 PM
@Steve_Lockstep For externalized authz examples, ‘To the Cloud!’ ( well actually to @ggebel ) @benatnovell @brad_tumy @NishantK
4/8/11 6:39 AM
@Steve_Lockstep @paulmadsen @benatnovell @nishantk I think the Federal ICAM BAE is a good source
4/8/11 8:26 AM
@brad_tumy @steve_lockstep @paulmadsen @benatnovell @nishantk I think @aniltj could add some insight as well to use cases for external authz
4/8/11 8:31 AM

Creating self-signed certs for a development environment. #Oracle #IDM #PKI

Implementing Identity and Access Management requires working with PKI certs to secure communication channels. For development purposes you can create your own self-signed certificates. I use OpenSSL as the RootCA (Signing Authority) and keytool as interface to the Java Key Store (JKS).

The following outlines the steps required to create a RootCA, generate a certificate request, sign the request and then import the signed certificate back into the JKS.

A few notes about my environment:

  • These instructions were validated on Oracle Enterprise Linux (for most flavors of Linux these instructions will be the same)
  • OpenSSL and Keytool were already installed on the server
  • In my example everything was installed on the same server … your OpenSSL instance may be on a different server.
  • OpenSSL and Keytool are available on my users $PATH … yours may not be.

So, let’s do this thing …

Configure a CA, using OpenSSL

  1. Create a working directory:mkdir /opt/rootCA
  2. Under /opt/rootCA make the following directories: private, certs, newcerts
  3. Change the permissions of rootCA (and subdirectories):chmod -R 700 /opt/rootCA
  4. From the /opt/rootCA directory, find (system wide) and make a local copy of the openssl.cnf (/opt/rootCA/openssl.cnf). You do not have to use the default configuration file that is installed with OpenSSL. In my case it was owned by root and I couldn’t change it anyway. So, I made a copy of it and was able to make the changes I needed. Note: I set all of the attributes to optional because I kept getting an error when I tried to sign the certificate that some of the required attributes were missing from the server certificate (maybe a bug??)
  5. Create the CA certificate:openssl req -new -x509 -extensions v3_ca -keyout private/cakey.pem -out cacert.pem -days 365 -config ./openssl.cnf

Create a keystore and private key:

keytool -genkey -alias alias -keyalg RSA -keysize 1024 -dname “server dn” -keypass keypass -keystore keystore.jks -storepass storepass

Create a certificate request (CSR) from the application server:

keytool -certreq -v -alias alias -file servername.csr -keypass keypass -storepass storepass -keystore ./keystore.jks

Sign the Certificate Requst:

  1. Sign the CSRopenssl ca -config openssl.cnf -in ../Middleware/keystores/servername.csr -out newcerts/servername.pem

Import the Trusted Root CA into the servers keystore:
keytool -import -v -noprompt -trustcacerts -alias rootcacert -file rootCA.cer -keystore keystore.jks -storepass storepass

Convert the signed cert (*.cer) into DER format (keytool preference) **

openssl x509 -outform der -in certificate.pem -out certificate.der

Import the signed cert into they server’s keystore:
keytool -import -v -alias alias-file servername.der -keystore keystore.jks -keypass keypass -storepass storepass

**Note: keytool whined that the cert was not in der format so, I used openssl to convert it.

I would love to hear feedback on these instructions and any steps that would make this easier.

Adding static attributes to #SAML Assertions in #OIF 11g #Oracle #Identity #IDM

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
Set up the WLST Environment:
The syntax to set up the environment on Linux systems is:

[e.g.  export DOMAIN_HOME=/apps/oracle/Middleware/user_projects/domains/IDMDomain/]

>source $ORACLE_HOME/fed/scripts/

(replace $ORACLE_HOME with the correct path for your environment.)
[e.g. source /apps/oracle/Middleware/Oracle_IDM1/fed/scripts/]
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.

Connecting to t3:// 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:
Execute the following (2) setConfigProperty commands.
[the following was provided by Oracle Corporation]
Oracle Identity Federation Configuration
  1. Enter the WLS scripting environment for the OIF instance.
  2. Set the authncontext property containing the root context of the post-processing plugin page
  3. Set the authnpath property containing the relative path of the post-processing plugin page:
  4. 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:


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(""); 

// 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(); 
attributes.put("application", values); 
attributes.put("siteid", values1); 

// Set the attribute map in the request. 

request.setAttribute("", 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.