DocTeger

OpenSSO Technical Information

And a Spoonful of Music

To Make the Medicine Go Down

Oracle and Sun: One Week

It's been one week since my last entry - and what a week it's been!

• Oracle finalized its acquisition of Sun.
• Larry Ellison and Oracle/Sun executives held a public strategy meeting regarding the Sun portfolio.
• JAVA was removed from the NASDAQ.
• A number of Sun employees were offered positions with Oracle.
• A number of Sun employees were not offered positions with Oracle.
• Rebranding began. (Check out the blogs.sun.com favicon.)

It's been a wild, winding road from when we first heard of the acquisition in April 2009. I'd like to wish my friends who have moved on the best of luck. I'd like to wish my friends who were offered jobs a hearty congratulations. Personally, being offered a position at Oracle was a wonderful birthday present (yesterday) and I look forward to continuing work under the Oracle favicon.

In the meantime, check out the Barenaked Ladies and their only number one hit, One Week.

Posted at 11:14AM Feb 02, 2010 by Michael Teger in Sun  |  Comments[2]

Eyes Only: OpenSSO Express 9 Documentation

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.

Posted at 04:43PM Jan 26, 2010 by Michael Teger in Sun  |  Comments[2]

Sun & Oracle: EU Has No More Tears

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.

Posted at 09:58AM Jan 21, 2010 by Michael Teger in Sun  |  Comments[0]

Using OpenSSO with Microsoft Geneva Server

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.

Posted at 12:52PM Jan 19, 2010 by Michael Teger in Sun  |  Comments[0]

Managing OpenSSO Entitlements Using REST: The End

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.

Posted at 10:03AM Jan 15, 2010 by Michael Teger in Sun  |  Comments[2]

Evaluating OpenSSO Entitlements Using REST

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.

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.

• 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

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.anotherexample.com:80/index.html using the GET method from the client IP address 125.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.

Posted at 10:31AM Jan 14, 2010 by Michael Teger in Sun  |  Comments[2]

Listening for the OpenSSO Entitlements Service Using REST

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.

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.

• 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.

Posted at 09:34AM Jan 13, 2010 by Michael Teger in Sun  |  Comments[0]

Authenticating for the OpenSSO Entitlements Service REST Interfaces

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.

1. Compile the Encoder.java code found on opensso.dev.java.net.
   javac Encoder.java
2. 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.

---

Posted at 11:53AM Jan 12, 2010 by Michael Teger in Sun  |  Comments[2]

Born To Change a Configured OpenSSO Host Name

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 configuration 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 configuration 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.

1. Login to the OpenSSO console as administrator; by default, amadmin.
2. Click the Access Control tab.
3. Click / Top Level Realm.
4. Add the new host name as a value for the Realm/DNS Aliases attribute. For example, new.example1.com.
5. Export the service configuration data to a file named export.xml.
   See Backing Up and Restoring Configuration Data for information.
6. Copy export.xml to new.xml.
7. Open new.xml and make the following changes.
   1. Search for <SubConfiguration 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>
   2. Search for <Service name=”iPlanetAMAuthConfiguration” version=”1.0”><Schema i18nFileName=”amAuthConfig” i18nKey=”iplanet-am-auth-config-service-description” propertiesViewBeanURL=”opensso/auth/ACServiceInstanceList”> and change opensso to opensso1.
   3. Search for <SubSchema inheritance=”multiple” maintainPriority=”no” name=”NamedConfiguration” supportsApplicableOrganization=”no” validate=”yes”><AttributeSchema cosQualifier=”default” i18nKey=”a101” isSearchable=”no” name=”iplanet-am-auth-configuration” propertiesViewBeanURL=”opensso/auth/ACModuleList”> and change opensso to opensso1.
   4. Search for <AttributeSchema cosQualifier=”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/.
   5. Search for <AttributeValuePair><Attribute name=”sunOrganizationAliases”/><Value>opensso</Value> and change opensso to opensso1.
   6. Search for <AttributeSchema cosQualifier=”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.
   7. 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
8. Save new.xml.
9. 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.
10. Import new.xml back into OpenSSO.
    See Backing Up and Restoring Configuration Data for information.
11. Stop the web container.
12. 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.
13. Change the deploy context on the OpenSSO web container to opensso1.
    Check the your web container's documentation for instructions.
14. Move OpenSSO-ConfigDir/opensso to OpenSSO-ConfigDir/opensso1.
    Be sure to backup this directory first.
15. Change to the user-home/.openssocfg directory.
    A file named with the prefix AMConfig is in this directory; for example, AMConfig_usr_local_tomcat_webapps_opensso or AMConfig_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.
16. Change opensso in the AMConfig* file to opensso1.
17. Start the web container.
18. Log in to OpenSSO using the new URL (and host name) as amadmin.
19. Click the Access Control tab.
20. Click / Top Level Realm.
21. 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.

1. Edit OpenSSO-ConfigDir/bootstrap by changing the new encoded URL back to the old encoded URL.
2. Import export.xml back into OpenSSO.
3. Change the deploy context on the OpenSSO web container back to opensso.
4. Move OpenSSO-ConfigDir/opensso1 to OpenSSO-ConfigDir/opensso.
5. Change opensso1 in the AMConfig* file (located in the user-home/.openssocfg directory) back to opensso.
6. Restart the web container.

Now enjoy Patrick Hernandez's one hit Born to Be Alive.

Posted at 12:32PM Jan 08, 2010 by Michael Teger in Sun  |  Comments[6]

Happy New Year Authenticating to OpenSSO Monitoring Service

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.

Posted at 12:00AM Jan 05, 2010 by Michael Teger in Sun  |  Comments[0]

Importing the Root CA Certificate for Secure OpenSSO Rainbow Connections

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.

Posted at 09:34AM Dec 22, 2009 by Michael Teger in Sun  |  Comments[2]

A URL List for the Relay State You're In

When an identity provider and a service provider are communicating using SAMLv2 (a redirect or an assertion exchange, for example), the RelayState parameter is used to store the URL to which the user will be redirected after the action (single sign-on, single log out or termination, for example) is complete. (If a RelayState value is not specified, the value of the defaultRelayState property in the extended metadata configuration of the entity provider is used. See Constructing SAML Messages in the Sun OpenSSO 8.0 Developer's Guide for more information.)

To avoid the RelayState parameter's being used to redirect the user to an invalid site, the Relay State URL List has been added as an Advanced property in the Standard Administration Console to the hosted identity provider, the hosted service provider and the Fedlet metadata. The value of this property is essentially a white list of URLs. If the property contains no URLs, no further check is done and the user is redirected to the URL value of the RelayState parameter as per usual. If URLs are specified, both the hosted identity provider and hosted service provider (or Fedlet, if applicable) will check the value of the RelayState parameter in the communication against the URLs and, if there is a match, redirection to the value of the RelayState parameter is allowed. If there is no match, the user is shown a browser error indicating Invalid Relay State URL specified.

To add to the Relay State URL List, log in to the OpenSSO Standard Administration Console as administrator.

1. Click the Federation tab.
2. Click the name of the appropriate hosted entity provider from the Entity Providers table.
3. Click the Advanced tab.
4. Click Relay State URL List (or scroll to the page's bottom).
5. Add one or more URLs based on the following supported patterns.
   • *
   • http://host:port/*
   • http://*:*/* - (if no port number is specified, defaults to 80 as the protocol is http)
   • https://*:*/* - (if no port number is specified, defaults to 443 as the protocol is https)
   • http://*:*/*?* - (if query string is present)
   • http://host:port/-*-/test - (one level wild card support)
6. Click Save.

Now enjoy this video from (very early) Bananarama - State I'm In. They look like they're in a Dexy's Midnight Runners state.

Or if you prefer the Squeaky Mix - half the time, double the BPM and quadruple the laughs.

Posted at 02:05PM Dec 21, 2009 by Michael Teger in Sun  |  Comments[2]

If You Have To Change The amadmin Password Out of the Box

Since the password for amadmin is encoded and hashed it is hard to change the password once OpenSSO is installed as we don't offer the option or utility to encode and hash the password. Unofficially, there is a way to change the lost or forgotten password of amadmin. It's not supported and this is the only thing written on it so be sure not to lose or forget your password. But just in case...

BEFORE YOU BEGIN: The password for amadmin and Directory Manager of the configuration data store is the same by default. So before you can make any changes to the configuration data store, you will need to reset the password for the OpenDS Directory Manager. Use the ldappasswordmodify command as illustrated:

$ ldappasswordmodify -h localhost -p 1389 --authzID "dn:cn=Directory Manager" --currentPassword mypassword --newPassword mynewpassword

It should return:

The LDAP password modify operation was successful

Now follow these instructions to reconfigure the configuration data store using the new Directory Manager password when it is requested.

1. Connect to the Configuration Data Store using an LDAPBROWSER client.
2. Navigate to --> ou=Services --> ou=iPlanetAMPlatformService --> ou=1.0 --> ou=GlobalConfig --> ou=Default --> ou=com-sun-identity-servers --> ou=http://:/opensso.
3. Select ou=http://:/opensso. Its different attributes and associated values are displayed on the right. Note the value of attribute sunKeyValue displays serverconfig=am.encryption.pwd=password1234. If there is another instance of OpenSSO that has the same value for am.encryption.pwd as this one, the passwords and encryptions are the same. Continue with step 5 to change the password. Otherwise, continue with step 4.
4. Install an instance of OpenSSO in a test environment using the same value of am.encryption.pwd as the one above.
5. Connect to the Configuration Data Store on the temporary instance using an LDAPBROWSER client.
6. Navigate to to --> ou=Services --> ou= sunIdentityRepositoryService --> ou=1.0 --> ou=GlobalConfig --> ou=Default --> ou=users --> ou=amAdmin.
7. Select ou=amAdmin. Its different attributes and associated values are displayed on the right. The value of sunKeyValue is displayed as userPassword=AQICGCVs587Ld67ZkiWlqauzaXQAqvx8g6YECMW/jzK62WNdhnBceHNEwg==.
8. Navigate to the Configuration Data Store on which you want to change the password and replace the old value with this new one.
9. Restart the web container.
10. Login using the password of the temporary environment that was copied.

And now enjoy Wanda Jackson performing The Box That It Came In. She's pretty angry but it has nothing to do with the out-of-the-box password.

Posted at 04:36PM Dec 15, 2009 by Michael Teger in Sun  |  Comments[0]