For Your Eyes Only: OpenSSO Express 9 Documentation

docteger — Tue, 26 Jan 2010 16:43:35 +0000

In anticipation of the release of OpenSSO Express 9, we’ve uncovered the documentation. The Parent Page for OpenSSO Express 9 contains links to wiki articles you may not (or may ;>) have seen including:

Authenticating to the OpenSSO Express 9 Monitoring Service
Configuring the OpenSSO Express 9 Java Fedlet for XACML Query
More Entitlements Service Subcommands and Options for the ssoadm Command Line Interface in OpenSSO Express 9
Deploying OpenSSO Express 9 on an IBM WebSphere Application Server 7.0 Web Container
OpenSSO Express 9 MIB File for Monitoring Service
Rebuilding the Indexes for an Embedded OpenDS Data Store in OpenSSO Express 9
XACML Subcommands and Options for the ssoadm Command Line Interface in OpenSSO Express 9
Implementing ASP.NET Fedlet Single Logout with OpenSSO Express 9
Introducing the OpenSSO Express 9 Entitlements Service REST Interfaces
New Functionality for the OpenSSO Express 9 Java Fedlet
New Functionality for Web Services Security in OpenSSO Express 9
New Functionality in the OpenSSO Express 9 Standard and Beta Administration Consoles
Using the OpenSSO Express 9 REST Privilege Management Interfaces
Introducing the OpenSSO OAuth Token Service (Express 9 Early Access)
Rebuilding the OpenDS Indexes for a Remote User Data Store in OpenSSO Express 9
Using Microsoft Active Directory 2008 as the OpenSSO Express 9 User Data Store
Using the OpenSSO Express 9 REST Listener Management Interfaces
Using the OpenSSO Express 9 REST Policy Evaluation Interfaces

Now check out Sheena Easton singing the James Bond theme, For Your Eyes Only.

Sun & Oracle: EU Has No More Tears

docteger — Thu, 21 Jan 2010 09:58:19 +0000

The European Union cleared Oracle’s acquisition of Sun this morning.

At the same time, Barbra Streisand and Donna Summer cleared the release of this tape of the two singing No More Tears (Enough is Enough). It’s a capella and direct from the studio.

Using OpenSSO with Microsoft Geneva Server

docteger — Tue, 19 Jan 2010 12:52:14 +0000

I just posted MICROSOFT® “GENEVA” SERVER AND SUN OPENSSO: ENABLING UNPRECEDENTED COLLABORATION ACROSS HETEROGENEOUS IT ENVIRONMENTS. This paper (written by another) focuses on Sun OpenSSO Enterprise and Microsoft Geneva Server — specifically, on their common support for the Security Assertion Markup Language (SAML) federation standard as a basis for interoperability. The paper:

Presents an overview of solutions and capabilities, both individual and interoperable solutions.
Describes the business benefits of interoperability between the two.
Shares detailed use cases demonstrating proven interoperability in real-world federation scenarios.

But before you leave, it’s not Geneva, it’s Vienna by Utravox.

Managing OpenSSO Entitlements Using REST: The End

docteger — Fri, 15 Jan 2010 10:03:39 +0000

This is the fourth and final part (the end) of a four part series on the OpenSSO REST interfaces for the Entitlements Service. Part one is Authenticating for the OpenSSO Entitlements Service REST Interfaces, part two is Listening for the OpenSSO Entitlements Service Using REST, and part three is Evaluating OpenSSO Entitlements Using REST.

With the upcoming release of OpenSSO Express 9, REST interfaces in the form of URLs have been developed to search, get, add, modify and remove Entitlement Service privileges (policies). The privilege management interfaces support both HTTP GET, PUT, DELETE, and POST actions, and return JavaScript Object Notation (JSON) objects.

The privilege management URLs begin with the base which can be appended with a specific string based on the action desired. One or more parameters are then added based on the information required by the action. The format of the OpenSSO REST privilege management URL is:

http://OSSO-host:OSSO-port/opensso/ws/1/entitlement/privilege/OpenSSO-REST-string?parameter1=value1&parameter2=value2&parameterN=valueN

To search for a privilege or add a new configuration, use the base URL (http://OSSO-host:OSSO-port/opensso/ws/1/entitlement/privilege/), replace OpenSSO-REST-string with the appropriate privilege name, and append the appropriate parameters. If the value of the parameters (value1, value2, …, valueN) contains unsafe characters, they need to be URL encoded when forming the REST URL. For example, an equal sign (=) needs to be replaced with %3D or an ampersand (&) needs to be replaced with %26.

NOTE: Prior to making a call using one of these RESTful interfaces, the subject must authenticate to OpenSSO and get a session token identifier. The SHA1 hashed value of this token.id then needs to be base64 encoded and used as input for these REST URLs. See Authenticating for the OpenSSO Entitlements Service REST Interfaces for more information.

The following sections contain more information.

Searching for Privileges
Adding a New Privilege
Retrieving a Privilege Configuration
Modifying an Existing Privilege
Removing an Existing Privilege

Searching for Privileges

The privilege interface uses HTTP GET to return a JSON string that lists the configured privileges under a particular realm; by default, the / Top Level Realm is searched. The URL may be populated with the following information.

subject defines the requesting user using the URL encoded value of the encoded token.id.
filter defines criteria to narrow down the privileges searched. For example, if there are privileges named as a1, a2, b1 and b2, the filter name=a* would narrow the search to privileges that begin with a. The default value is name=*.

For example:

http://www.example.com:8080/opensso/ws/1/entitlement/privilege?
subject=vd6RXuEnYJl93VWftk9plOzAqfQ%3D
&filter=name%3Da*

This REST call returns a JSON string. The example below means that there is a privilege named example1 under the top level realm.

{
"statusCode":200,
"statusMessage":"OK",
"body":{
"result":[
"example1"
]
}
}

Adding a New Privilege

The privilege interface also uses HTTP POST to add a JSON representation of the defined privilege to the Entitlement Service under a particular realm; by default, the / Top Level Realm. The URL may be populated with the following information.

subject defines the requesting user using the URL encoded value of the encoded token.id.
privilege.json defines the privilege configuration as a JSON representation.

For example:

http://www.example.com:8080/opensso/ws/1/entitlement/privilege?
subject=vd6RXuEnYJl93VWftk9plOzAqfQ%3D
&privilege.json=JSON-representation-of-the-privilege

This second example of the REST call is displayed as it might be in an HTTP message to illustrate the request and response exchange of HTTP POST.

POST /opensso/ws/1/entitlement/privilege HTTP/1.1
subject=vd6RXuEnYJl93VWftk9plOzAqfQ%3D
&privilege.json=JSON-representation-of-the-privilege

It returns a JSON string representing the outcome of the action. The example below means a successful POST.

{
"statusCode":201,
"statusMessage":"Created",
"body":"Created"
}

Retrieving a Privilege Configuration

To get the configuration for a specific privilege, append the privilege name and parameter to the end of the URI. The interface uses HTTP GET to return a JSON representation of the defined privilege. The only parameter is the URL encoded value of the encoded token.id that defines the subject.

http://www.example.com:8080/opensso/ws/1/entitlement/privilege/example1?
subject=vd6RXuEnYJl93VWftk9plOzAqfQ%3D

This REST call returns a JSON representation of privilege example1. The example below means that the subject accessing http://www.example.com must be authenticated.

{
"statusCode":200,
"statusMessage":"OK",
"body":{
"result":"{
\"name\":\"example1\",
\"description\":\"desciption\",
\"eSubject\":{
\"state\":\"\",
\"className\":\"com.sun.identity.entitlement.AuthenticatedESubject\"
},
\"entitlement\":{
\"name\":\"entitlement\",
\"applicationName\":\"iPlanetAMWebAgentService\",
\"resourceNames\":[
\"http://www.example.com/*\"
]
\"actionsValues\":{
\"GET\":true
},
}
}"
}
}

Modifying an Existing Privilege

To modify the configuration of an existing privilege, append the privilege name and parameters after the URI. The interface uses HTTP PUT to modify the defined privilege based on a JSON representation used as input. The URL may be populated with the following information.

The privilege being modified is defined by the OpenSSO-REST-string variable of the URL. In the following example, the privilege being modified is example2.
subject defines the requesting user using the URL encoded value of the encoded token.id.
privilege.json defines the new privilege configuration as a JSON representation.


http://www.example.com:8080/opensso/ws/1/entitlement/privilege/example2?

subject=vd6RXuEnYJl93VWftk9plOzAqfQ%3D
&privilege.json=JSON-representation-of-the-privilege

This second example of the REST call is displayed as it might be in an HTTP message to illustrate the request and response exchange of HTTP PUT.

PUT /opensso/ws/1/entitlement/privilege/example2 HTTP/1.1
subject=vd6RXuEnYJl93VWftk9plOzAqfQ%3D
&privilege.json=JSON-representation-of-the-privilege

This REST call returns a JSON string representing the outcome of the action. The example below means a successful PUT.

{
"statusCode":200,
"statusMessage":"OK",
"body":{
"result":"OK"
}
}

Removing an Existing Privilege

To remove an existing privilege, append the privilege name and parameter after the URI. The interface uses HTTP DELETE to remove the defined privilege. The parameter is the URL encoded value of the encoded token.id that defines the subject.


http://www.example.com:8080/opensso/ws/1/entitlement/privilege/example2?

subject=vd6RXuEnYJl93VWftk9plOzAqfQ%3D

This second example of the REST call is displayed as it might be in an HTTP message to illustrate the request and response exchange of HTTP DELETE.

DELETE /opensso/ws/1/entitlement/privilege/example1?subject=vd6RXuEnYJl93VWftk9plOzAqfQ%3D HTTP/1.1

This REST call returns a JSON string representing the outcome of the action. The example below means a successful DELETE.

{
"statusCode":200,
"statusMessage":"OK",
"body":{
"result":"OK"
}
}

I couldn’t decide whether to end this series with The Doors The End or Nancy Sinatra’s The End. While searching around I found that Nancy’s song was being used in a television commercial so here it is (the song not the commerical) with pix of the minx herself.

Evaluating OpenSSO Entitlements Using REST

docteger — Thu, 14 Jan 2010 10:31:52 +0000

This is part three of a four part series on the OpenSSO REST interfaces for the Entitlements Service. Part one is Authenticating for the OpenSSO Entitlements Service REST Interfaces, part two is Listening for the OpenSSO Entitlements Service Using REST, and part four is Managing OpenSSO Entitlements Using REST.

With the upcoming release of OpenSSO Express 9, REST interfaces in the form of URLs have been developed to evaluate policies and return decisions from the Entitlements Service. All of the policy evaluation interfaces support HTTP GET and POST actions, and some of them return JavaScript Object Notation (JSON) objects.

The policy evaluation URLs begin with the base which is appended with a specific string based on the action desired. One or more parameters are then added based on the information required by the action. The format of the OpenSSO REST policy evaluation URL is:

http://OSSO-host:OSSO-port/opensso/ws/1/entitlement/OpenSSO-REST-string?parameter1=value1&parameter2=value2&parameterN=valueN

The available policy evaluation interfaces (which replace OpenSSO-REST-string in the URL) are decision, entitlement, decisions, and entitlements. If the value of the parameters (value1, value2, …, valueN) contains unsafe characters, they need to be URL encoded when forming the REST URL. For example, an equal sign (=) needs to be replaced with %3D or an ampersand (&) needs to be replaced with %26.

The following sections contain more information.

Evaluating a Decision for One Resource
Evaluating a Decision and Returning Additional Information for One Resource
Evaluating a Decision for Multiple Resources
Evaluating a Decision for A Root and Sub Tree Resources

Evaluating a Decision for One Resource

The decision interface returns a plain text string of deny or allow in regards to a request for access. The URL may be populated with the following information.

subject defines the requesting user using the URL encoded value of the encoded token.id.
action defines the action to be evaluated.
application defines the requested service. This is an optional parameter and the default value is iPlanetAMWebAgentService.
resource defines the resource to be evaluated.
env defines an optional environment map. This map may contain information such as the date and time or the IP address of the client. There is no default parameter. Accepted values include:
1. requestDnsName – The value would be a set of strings representing the DNS names of the client from which the user is making the request in the form ccc.ccc.ccc. If the env parameter is null or does not define a requestDnsName value, the value is obtained from the user’s SSOToken.
2. requestIp – The value would be a string representation of the IP address of the client from which the user is making the request in the form n.n.n.n where n is a value between 0 and 255, inclusive; for example, env=requestIp%3D125.12.133.1.
3. requestTime – For example, env=requestTime%3D1248994000000.
4. requestTimeZone – The value would be a Java TimeZone object; for example, an abbreviation such as PST, a full name such as America/Los_Angeles or a custom ID such as GMT-8:00. See the TimeZone Java API Reference for more information.

For example:

http://www.example.com:8080/opensso/ws/1/entitlement/decision?
subject=vd6RXuEnYJl93VWftk9plOzAqfQ%3D
&action=GET
&application=iPlanetAMWebAgentService
&resource=http://www.example.com:80/index.html
&env=requestIp%3D125.12.122.4

This example REST call might return a plain text allow if the subject has permission to access http://www.example.com:80/index.html with GET method and client IP address 125.12.122.4.

Evaluating a Decision and Returning Additional Information for One Resource

The entitlement interface returns a list of JSONEntitlement objects in regards to a request for access. Although similar to the decision interface, it allows more information to be returned. The URL may be populated with the following information.

subject defines the requesting user using the URL encoded value of the encoded token.id.
application defines the requested service. This is an optional parameter and the default value is iPlanetAMWebAgentService.
resource defines the resource to be evaluated.
env defines an optional environment map. This map may contain information such as the date and time or the IP address of the client. There is no default parameter. Accepted values include:
1. requestDnsName – The value would be a set of strings representing the DNS names of the client from which the user is making the request in the form ccc.ccc.ccc. If the env parameter is null or does not define a requestDnsName value, the value is obtained from the user’s SSOToken.
2. requestIp – The value would be a string representation of the IP address of the client from which the user is making the request in the form n.n.n.n where n is a value between 0 and 255, inclusive; for example, env=requestIp%3D125.12.133.1.
3. requestTime – For example, env=requestTime%3D1248994000000.
4. requestTimeZone – The value would be a Java TimeZone object; for example, an abbreviation such as PST, a full name such as America/Los_Angeles or a custom ID such as GMT-8:00. See the TimeZone Java API Reference for more information.

For example:

http://www.example.com:8080/opensso/ws/1/entitlement/entitlement?
subject=vd6RXuEnYJl93VWftk9plOzAqfQ%3D
&application=iPlanetAMWebAgentService
&resource=http://www.example.com:80/index.html
&env=requestIp%3D125.12.122.4

{
"statusCode":200,
"statusMessage":"OK"
"body":{
"actionsValues":{"GET":true},
"attributes":{},
"advices":{},
"resourceName":"http://www.anotherexample.com:80/index.html"
}
}

Evaluating a Decision for Multiple Resources

The decisions interface returns a list in the form of a JSONEntitlements object in regards to a request for access to a set of resources. The URL may be populated with the following information.

subject defines the requesting user using the URL encoded value of the encoded token.id.
application defines the requested service. This is an optional parameter and the default value is iPlanetAMWebAgentService.
resources defines the set of resources to be evaluated. More than one resources parameter may be added to the URL.
env defines an optional environment map. This map may contain information such as the date and time or the IP address of the client. There is no default parameter. Accepted values include:
1. requestDnsName – The value would be a set of strings representing the DNS names of the client from which the user is making the request in the form ccc.ccc.ccc. If the env parameter is null or does not define a requestDnsName value, the value is obtained from the user’s SSOToken.
2. requestIp – The value would be a string representation of the IP address of the client from which the user is making the request in the form n.n.n.n where n is a value between 0 and 255, inclusive; for example, env=requestIp%3D125.12.133.1.
3. requestTime – For example, env=requestTime%3D1248994000000.
4. requestTimeZone – The value would be a Java TimeZone object; for example, an abbreviation such as PST, a full name such as America/Los_Angeles or a custom ID such as GMT-8:00. See the TimeZone Java API Reference for more information.

For example:

http://www.example.com:8080/opensso/ws/1/entitlement/decisions?
subject=vd6RXuEnYJl93VWftk9plOzAqfQ%3D
&application=iPlanetAMWebAgentService
&resources=http://www.example1.com:80/index.html
&resources=http://www.example2.com:80/index.html
&resources=http://www.example3.com:80/index.html
&env=requestIp%3D125.12.122.4

In the following result for this example, statusCode":200 signifies that the REST call has succeeded. Additionally, the policy evaluation confirms that the subject has permission to access http://www.example2.com:80/index.html using the GET method from the client IP address 125.12.122.4. The subject does not have permission, though, to access http://www.example2.com:80/index.html using the GET method from the client IP address 125.12.122.4 because it does not fall within the specified range defined as a condition of the policy: 128.122.18.1 to 128.122.18.254. No decision has been made for the third resource, http://www.example3.com:80/index.html.

{
"statusCode":200,
"statusMessage":"OK"
"body":{
"results":[
{
"actionsValues":{"GET":true},
"attributes":{},
"advices":{},
"resourceName":"http://www.example1.com:80/index.html"
}
{
"actionsValues":{"GET":false},
"attributes":{},
"advices":{
"com.sun.identity.entitlement.IPCondition":[
"requestIp=128.122.18.1-128.122.18.254"
]
},
"resourceName":"http://www.example2.com:80/index.html"
}
{
"actionsValues":{},
"attributes":{},
"advices":{},
"resourceName":"http://www.example3.com:80/index.html"
}
]
},
}

Evaluating a Decision for A Root and Sub Tree Resources

The entitlements interface takes a given root resource and provides the decisions for all of its sub resources. It returns a list in the form of a JSONEntitlements object in regards to the request for access. For example, given the root resource of http://www.example.com, results for all sub resources (including http://www.example.com/hr/*, http://www.example.com/eng/* and http://www.example.com/sales/*) will be returned. The URL may be populated with the following information.

subject defines the requesting user using the URL encoded value of the encoded token.id.
application defines the requested service. This is an optional parameter and the default value is iPlanetAMWebAgentService.
resource defines the root of the set of resources to be evaluated.
env defines an optional environment map. This map may contain information such as the date and time or the IP address of the client. There is no default parameter. Accepted values include:
1. requestDnsName – The value would be a set of strings representing the DNS names of the client from which the user is making the request in the form ccc.ccc.ccc. If the env parameter is null or does not define a requestDnsName value, the value is obtained from the user’s SSOToken.
2. requestIp – The value would be a string representation of the IP address of the client from which the user is making the request in the form n.n.n.n where n is a value between 0 and 255, inclusive; for example, env=requestIp%3D125.12.133.1.
3. requestTime – For example, env=requestTime%3D1248994000000.
4. requestTimeZone – The value would be a Java TimeZone object; for example, an abbreviation such as PST, a full name such as America/Los_Angeles or a custom ID such as GMT-8:00. See the TimeZone Java API Reference for more information.

For this example, assume that http://www.examplefour.com:80 has two sub resources: /index.html and /hr/index.html.

http://www.example.com:8080/opensso/ws/1/entitlement/entitlement?
subject=vd6RXuEnYJl93VWftk9plOzAqfQ%3D
&application=iPlanetAMWebAgentService
&resource=http://www.examplefour.com:80
&env=requestIp%3D125.12.122.4

In the following result statusCode":200 signifies that the REST call has succeeded. Additionally, the policy evaluation confirms that the subject has permission to access http://www.examplefour.com:80/index.html using the GET method from the client IP address 125.12.122.4. The subject does not have permission, though, to access http://www.examplefour.com:80/hr/index.html using the GET method from the client IP address 125.12.122.4 because it does not fall within the specified range defined as a condition of the policy: 128.122.18.1 to 128.122.18.254.

{
"statusCode":200,
"statusMessage":"OK"
"body":{
"results":[
{
"actionsValues":{},
"attributes":{},
"advices":{},
"resourceName":"http://www.anotherexample.com:80"
}
{
"actionsValues":{"GET":true},
"attributes":{},
"advices":{},
"resourceName":"http://www.anotherexample.com:80/index.html"
}
{
"actionsValues":{"GET":false},
"attributes":{},
"advices":{
"com.sun.identity.entitlement.IPCondition":[
"requestIp=128.122.18.1-128.122.18.254"
]
},
"resourceName":"http://www.anotherexample.com:80/hr/index.html"
}
]
},
}

Be aware though this will not work if you are wicked – as illustrated by Cage the Elephant in their song Ain’t No Rest for the Wicked.

Listening for the OpenSSO Entitlements Service Using REST

docteger — Wed, 13 Jan 2010 09:34:23 +0000

This is part two of a four part series on the OpenSSO REST interfaces for the Entitlements Service. Part one is Authenticating for the OpenSSO Entitlements Service REST Interfaces, part three is Evaluating OpenSSO Entitlements Using REST, and part four is Managing OpenSSO Entitlements Using REST.

There are RESTful management interfaces that can be used to get, add and remove listeners which send notifications to the Entitlements Service when privileges are added, removed, or modified. The listener management interfaces support HTTP GET, DELETE, and POST actions, and returns a JavaScript Object Notation (JSON) object.

The listener management URLs begin with the base which is appended with the encoded URL of the listener. One or more parameters are then added based on the information required by the action. The format of the OpenSSO REST listener management URL is:

http://OSSO-host:OSSO-port/opensso/ws/1/entitlement/listener/encoded-URL?parameter1=value1&parameter2=value2&parameterN=valueN

To get or remove a listener configuration, use the base of the URL (http://OSSO-host:OSSO-port/opensso/ws/1/entitlement/listener/) and replace encoded-URL with the appropriate listener URL. To add a new listener, append the base URL with the appropriate parameters. If the value of the parameters (value1, value2, …, valueN) contains unsafe characters, they need to be URL encoded when forming the REST URL. For example, an equal sign (=) needs to be replaced with %3D or an ampersand (&) needs to be replaced with %26.

Adding a Listener
Retrieving a Listener
Removing a Listener

Adding a Listener

This interface uses HTTP POST to add the listener configuration for the specified resource. The URL may be populated with the following information.

url defines the URL of the listener.
subject defines the requesting user using the URL encoded value of the encoded token.id.
application defines the generic resource type. See The Entitlements Service In OpenSSO Express 8 for more information.
resources defines one or more resources for which the listener is configured.

For example:

http://www.example.com:8080/opensso/ws/1/entitlement/listener?
url=http%3A%2F%2Fwww.listenerexample.com%2Fnotification
&subject=vd6RXuEnYJl93VWftk9plOzAqfQ%3D
&resources=http://www.example1.com/*

This REST call returns a JSON object affirming the successful addition of the listener.

{
"statusCode":201,
"statusMessage":"Created",
"body":"Created"
}

Retrieving a Listener

This interface uses HTTP GET to return a JSON representation of the specified listener configuration. The URL may be populated with the following information.

encoded-URL is appended to the end of the REST URL (before the parameters) and is the encoded URL of the listener.
subject defines the requesting user using the URL encoded value of the encoded token.id.

For example:

http://www.example.com:8080/opensso/ws/1/entitlement/listener/
http%3A%2F%2Fwww.listenerexample.com%2Fnotification
&subject=vd6RXuEnYJl93VWftk9plOzAqfQ%3D

This REST call returns a JSON representation of the listener. The example below means that there is a listener for all privileges regarding _http://www.example1.com_.

{
"statusCode":200,
"statusMessage":"OK",
"body":{
"mapAppToRes":{
"iPlanetAMWebAgentService":[
"http://www.example1.com/*"
]
},
"url":"http://www.listenerresttest.com/notification"
}
}

Removing a Listener

This interface uses HTTP DELETE to remove the specified listener. The URL may be populated with the following information.

encoded-URL is appended to the end of the REST URL (before the parameters) and is the URL of the listener.
subject defines the requesting user using the URL encoded value of the encoded token.id.

For example:

http://www.example.com:8080/opensso/ws/1/entitlement/listener/
http%3A%2F%2Fwww.listenerexample.com%2Fnotification
&subject=vd6RXuEnYJl93VWftk9plOzAqfQ%3D

This REST call returns a JSON object affirming the successful removal of the listener.

{
"statusCode":200,
"statusMessage":"OK",
"body":{
"result":"OK"
}
}

And while we’re listening, here’s Pseudo Echo with their 1981 Aussie hit, Listening.

Authenticating for the OpenSSO Entitlements Service REST Interfaces

docteger — Tue, 12 Jan 2010 11:53:49 +0000

This is part one of a four part series on the OpenSSO REST interfaces for the Entitlements Service. Part two is Listening for the OpenSSO Entitlements Service Using REST, part three is Evaluating OpenSSO Entitlements Using REST, and part four is Managing OpenSSO Entitlements Using REST.

The OpenSSO Entitlements Service provides fine grained access control. With the upcoming release of OpenSSO Express 9, RESTful interfaces (in the form of URLs) have been developed for the Entitlements Service. (Information on other OpenSSO RESTful interfaces can be found .)

Before using the Entitlements Service REST interfaces, the user making the calls needs to be authenticated and receive a session token identifier. Following authentication, this identifier must be hashed and encoded for input as a parameter value of the Entitlements Service REST URLs. The following sections have more information.

Authenticating to OpenSSO Before Using REST
Encoding the token.id

Authenticating to OpenSSO Before Using REST

Before making a REST call using one of the Entitlements Service URLs, the subject must authenticate to OpenSSO using the authenticate REST identity interface. This identity call, if successful, will get a session token identifier for the subject that will then be used as input for the Entitlements Service REST URLs. An example of the authenticate REST URL is:

http://www.example.com:8080/opensso/identity/authenticate?username=user1&password=changeme

NOTE: For this use, the authenticate URL should use HTTP POST because (the default) HTTP GET logs the user information which might be a security issue in some deployments.

This authenticate call would return a session token.id; for example:

token.id=AQIC5wM2LY4Sfcy9rURsXTOXiNjG2VNFgjtPB6Cw1ICTIK4=@AAJTSQACMDE=#

This session token.id needs to be set as the iPlanetDirectoryPro cookie.

iPlanetDirectoryPro=AQIC5wM2LY4Sfcy9rURsXTOXiNjG2VNFgjtPB6Cw1ICTIK4=@AAJTSQACMDE=#

Additionally, a SHA1-hashed and base64 encoded string needs to be generated from the value of the token.id. This encoded string, representing the user, will be passed as a parameter with every REST call.

Encoding the `token.id`

This procedure will generate a SHA1-hashed and base64 encoded string from the session token.id previously returned.

Compile the Encoder.java code found on opensso.dev.java.net.
javac Encoder.java

Run the compiled Encoder to hash and encode the session token.id.
java Encoder AQIC5wM2LY4Sfcy9rURsXTOXiNjG2VNFgjtPB6Cw1ICTIK4=@AAJTSQACMDE=

The Encoder returns a string such as vd6RXuEnYJl93VWftk9plOzAqfQ=. This string is a SHA1 hash that is also base64 encoded. It must be passed as a parameter with every REST call to indicate the subject; for example:

subject=vd6RXuEnYJl93VWftk9plOzAqfQ=  
   The actual information on the Entitlements Service REST interfaces will be forthcoming. (And this entry will make more sense. ;> ) It includes policy evaluation, privilege management and listener management REST interfaces. In the meantime, take the Rest of the Day Off from Neil Finn's 2001 album - Bowie-esque from his Heroes period.



Born To Change a Configured OpenSSO Host Name
docteger — Fri, 08 Jan 2010 12:32:56 +0000
After opensso.war is deployed in a web container, the installed OpenSSO instance is uniquely identified by a URL defined with a protocol (http/https), a host name, a port and a deployment URI; for example, http://ipg-test2.sun.com:8080/opensso. This URL is defined in the OpenSSO bootstrap file as well as in various places in the service conﬁguration data store.   
  When the web container on which OpenSSO is deployed is restarted, OpenSSO uses the bootstrap URL to locate its system properties in the service conﬁguration data store and start itself. Additionally, almost all federation and web services endpoints contain this URL. Thus, to change the host name on which the instance of OpenSSO has been installed, use the first procedure in this entry. The second procedure documents how to restore the previous host name.  
  To Change the OpenSSO Host Name
 To Restore the Previous Configuration  
  

To Change the OpenSSO Host Name
  
   For this example procedure, assume the current OpenSSO URL is http://current.example.com:58080/opensso, and the new OpenSSO URL will be http://new.example1.com:8080/opensso1.   Login to the OpenSSO console as administrator; by default, amadmin.
 Click the Access Control tab.
 Click / Top Level Realm.
 Add the new host name as a value for the Realm/DNS Aliases attribute. For example, new.example1.com.
  Export the service conﬁguration data to a file named export.xml.
 See Backing Up and Restoring Configuration Data for information.
  Copy export.xml to new.xml.
  Open new.xml and make the following changes. Search for <SubConﬁguration name=”http://current.example.com:58080/opensso” id=”server”> and: Change <Value>com.iplanet.am.services.deploymentDescriptor=/opensso</Value> to <Value>com.iplanet.am.services.deploymentDescriptor=/opensso1</Value>
 Change <Value>com.iplanet.am.server.port=58080</Value> to <Value>com.iplanet.am.server.port=8080</Value>
  Change <Value>com.iplanet.am.server.host=current.example.com</Value> to  <Value>com.iplanet.am.server.host=new.example1.com</Value>
 Search for <Service name=”iPlanetAMAuthConﬁguration” version=”1.0”><Schema i18nFileName=”amAuthConﬁg” i18nKey=”iplanet-am-auth-conﬁg-service-description” propertiesViewBeanURL=”opensso/auth/ACServiceInstanceList”> and change opensso to opensso1.
  Search for <SubSchema inheritance=”multiple” maintainPriority=”no” name=”NamedConﬁguration” supportsApplicableOrganization=”no” validate=”yes”><AttributeSchema cosQualiﬁer=”default” i18nKey=”a101” isSearchable=”no” name=”iplanet-am-auth-conﬁguration” propertiesViewBeanURL=”opensso/auth/ACModuleList”> and change opensso to opensso1.
  Search for <AttributeSchema cosQualiﬁer=”default” i18nKey=”a133” isSearchable=”no” name=”iplanet-am-auth-login-success-url” syntax=”string” type=”list”><DefaultValues><Value>/opensso/console</Value> and change opensso/ to opensso1/.
 Search for <AttributeValuePair><Attribute name=”sunOrganizationAliases”/><Value>opensso</Value> and change opensso to opensso1.
  Search for <AttributeSchema cosQualiﬁer=”default” i18nKey=”a103” isSearchable=”no” name=”iplanet-am-platform-cookie-domains” syntax=”string” type=”list”><DefaultValues><Value>.example.com</Value> and change the cookie domain from .example.com to .example1.com.
  Substitute the following strings: http://new.example1.com:8080/opensso1 for http://current.example.com:58080/opensso
 new.example1.com:8080 for current.example.com:58080
 Save new.xml.
 Backup the OpenSSO configuration data.
This backup can be used to restore a previous configuration. If the OpenSSO configuration data store is the default embedded OpenDS, backup the contents of OpenSSO-ConfigDir. OpenSSO-ConfigDir represents the name of the directory specified during initial configuration of OpenSSO as the configuration directory. By default, an opensso directory would be created in the home directory of the user configuring the instance. Thus, if root is configuring the instance, OpenSSO-ConfigDir is /opensso.  If any other directory server is used, work with the administrator to back up the OpenSSO configuration data before proceeding.
 Import new.xml back into OpenSSO.
 See Backing Up and Restoring Configuration Data for information.
 Stop the web container.
  Replace http%3A%2F%2Fcurrent.example.com%3A58080%2Fopensso with http%3A%2F%2Fnew.example1.com%3A8080%2Fopensso1 in the OpenSSO-ConfigDir/bootstrap file.
 During OpenSSO deployment, a setup servlet creates a file named bootstrap in the OpenSSO configuration directory. This file contains the information that points to a location from which OpenSSO can retrieve configuration data to bootstrap itself. For more information on this file, see The OpenSSO Bootstrap File Deconstructed.
 Change the deploy context on the OpenSSO web container to opensso1.
Check the your web container’s documentation for instructions.
 Move OpenSSO-ConfigDir/opensso to OpenSSO-ConfigDir/opensso1.
Be sure to backup this directory first.
  Change to the user-home/.openssocfg directory.
 A ﬁle named with the preﬁx AMConﬁg is in this directory; for example, AMConﬁg_usr_local_tomcat_webapps_opensso or  AMConﬁg_opt_jboss-4.2.2.GA_server_fam2_._deploy_opensso.war_. user-home is the home directory of the user who configured the instance of OpenSSO.
 Change opensso in the AMConfig* file to opensso1.  
Start the web container.
 Log in to OpenSSO using the new URL (and host name) as amadmin.
 Click the Access Control tab.
 Click / Top Level Realm.
 Remove current.example.com, the old host name, from the Realm/DNS Aliases attribute.
  

To Restore the Previous Configuration
  
   This procedure is based on the examples and information used in the previous procedure.  
  Edit OpenSSO-ConfigDir/bootstrap by changing the new encoded URL back to the old encoded URL.
 Import export.xml back into OpenSSO.
 Change the deploy context on the OpenSSO web container back to opensso. 
 Move OpenSSO-ConfigDir/opensso1 to OpenSSO-ConfigDir/opensso.
  Change opensso1 in the AMConfig* file (loca

ted in the user-home/.openssocfg directory) back to opensso.  
Restart the web container.
  
  Now enjoy Patrick Hernandez’s one hit Born to Be Alive.  
  

         


Happy New Year Authenticating to OpenSSO Monitoring Service
docteger — Tue, 05 Jan 2010 00:00:00 +0000
A monitoring framework based on the Java Dynamic Management Kit (JDMK) was introduced in OpenSSO Express Build 8. Access to OpenSSO’s monitoring data may be via the HTTP, SNMP (Simple Network Management Protocol), or RMI (Remote Method Invocation) interfaces.   
  In OpenSSO Express Build 9 (and currently available in the nightly build), access to the Monitoring Service’s HTTP interface has been modified to require authentication to access OpenSSO monitoring data through the HTTP interface. (An HTML Protocol Adaptor comes with the JDMK and is used to authenticate. See The HTML Protocol Adaptor for more information.)  
  The opensso_mon_auth file contains the name and password of the user (or users) with permission to log in and see the OpenSSO monitoring data. It is located in the /ConfigurationDirectory/install-URI/ directory created during the OpenSSO installation; by default, /opensso/opensso/opensso_mon_auth. The file initially contains the user demo with an encrypted value equal to the password changeit. This user can be replaced or additional users added to the file. Type any user identifier followed by a space and the encrypted value of the user’s password. The user name is case-sensitive and the password must be encrypted using the ampassword command line tool. It is located in the ssoAdminTools.zip which is in the tools directory of the expanded opensso.zip. For more information see Installing the OpenSSO Enterprise Utilities and Scripts.  
  NOTE: The user in this file is not tied in any respect to the OpenSSO user data store. Authentication to the monitoring data using the HTML Protocol Adaptor is a separate authentication process from that of OpenSSO.  
  Now just a little wish from ABBA (and me, by proxy) for all to enjoy the new year and decade. Happy New Year from the Super Trouper LP – an acronym from many new years ago.  
  

         


Importing the Root CA Certificate for Secure OpenSSO Rainbow Connections
docteger — Tue, 22 Dec 2009 09:34:00 +0000
When configuring OpenSSO for a scenario that involves a secure connection (SSL or LDAPS) and multiple JVMs, you need to import the root CA certificate into the JVM trust store (by default JAVA_HOME/jre/lib/security/cacerts) and restart the OpenSSO web container before performing any configurations.   
  For example, to configure a second instance of OpenSSO in a defined Site (when the first instance of OpenSSO is SSL-enabled), the root Certificate Authority (CA) certificate for the first OpenSSO server certificate must be imported into the JVM key store of the web container in which the second instance of OpenSSO is deployed. (Restart the web container of the second instance after the import.)  
  An example of a command to import a root CA certificate to this key store is:  
  keytool -import -v -alias alias -keystore JAVA_HOME/jre/lib/security/cacerts -storepass changeit -file CAcert.crt  
  Use the following command to verify that the root CA certificate was imported correctly.  
  keytool -list -keystore JAVA_HOME/jre/lib/security/cacerts -storepass changeit  
  Now enjoy a secure Rainbow Connection with Deborah Harry and Kermit the Frog.

For Your Eyes Only: OpenSSO Express 9 Documentation

Sun & Oracle: EU Has No More Tears

Using OpenSSO with Microsoft Geneva Server

Managing OpenSSO Entitlements Using REST: The End

Searching for Privileges

Adding a New Privilege

Retrieving a Privilege Configuration

Modifying an Existing Privilege

Removing an Existing Privilege

Evaluating OpenSSO Entitlements Using REST

Evaluating a Decision for One Resource

Evaluating a Decision and Returning Additional Information for One Resource

Evaluating a Decision for Multiple Resources

Evaluating a Decision for A Root and Sub Tree Resources

Listening for the OpenSSO Entitlements Service Using REST

Adding a Listener

Retrieving a Listener

Removing a Listener

Authenticating for the OpenSSO Entitlements Service REST Interfaces

Authenticating to OpenSSO Before Using REST

Encoding the token.id

Born To Change a Configured OpenSSO Host Name

To Change the OpenSSO Host Name

To Restore the Previous Configuration

Happy New Year Authenticating to OpenSSO Monitoring Service

Importing the Root CA Certificate for Secure OpenSSO Rainbow Connections

Encoding the `token.id`