Friday Jan 08, 2010

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.

Wednesday Nov 25, 2009

Tail the OpenSSO SSOToken Then Go! Get Turkey

Here is an unofficial way to see the properties in the SSOToken. The SSOToken is the building block of an OpenSSO session. It is used to collect and retrieve session data such as the authenticated principal name, authentication method, session idle time and maximum session time. In order to see exactly what is in the SSOToken change the debug level of the OpenSSO server to Message.
  1. Log into the OpenSSO Console as administrator.
  2. Click the Configuration tab.
  3. Click the Servers and Sites tab.
  4. Click the appropriate server link in the Servers table.
  5. Click the debugging link.
  6. Select Message from the drop down options.
  7. Click Save.
Now, on the command line, tail the Session Service debug log. The debug files are located in the opensso configuration directory. For example, when OpenSSO is deployed using Glassfish, you can find Session in /opensso/opensso/debug.

tail Session

Now login as any configured user and then logout that user. The Session debug log will display the details of the SSOToken being destroyed as in the following display.

amSession:11/10/2009 12:38:26:619 PM PST: Thread[httpSSLWorkerThread-8080-4,10,Grizzly]
SESSION NOTIFICATION : <Session sid="AQIC5wM2LY4SfcyyvOv3Tm/JuNoXMKfnEd85nsdDk+wUiEc=@AAJTSQACMDE=#"
 stype="user" cid="uid=upgradeuser,ou=people,dc=red,dc=iplanet,dc=com" cdomain="dc=red,dc=iplanet,dc=com"
 maxtime="120" maxidle="30" maxcaching="3" timeidle="10" timeleft="7190" state="destroyed">
<Property name="CharSet" value="UTF-8"></Property>
<Property name="UserId" value="upgradeuser"></Property>
<Property name="FullLoginURL" value="/opensso/UI/Login?module=LDAP"></Property>
<Property name="successURL" value="/opensso/console"></Property>
<Property name="cookieSupport" value="true"></Property>
<Property name="AuthLevel" value="0"></Property>
<Property name="SessionHandle" value="shandle:AQIC5wM2LY4Sfcyl+XOus5I2hMB3fSXnY89LPuRsnyRinQ8=@AAJTSQACMDE=#"></Property>
<Property name="UserToken" value="upgradeuser"></Property>
<Property name="loginURL" value="/opensso/UI/Login"></Property>
<Property name="IndexType" value="module_instance"></Property>
<Property name="Principals" value="uid=upgradeuser,ou=people,dc=red,dc=iplanet,dc=com"></Property>
<Property name="moduleAuthTime" value="LDAP+2009-11-10T20:38:16Z|anon1+2009-11-10T20:37:44Z"></Property>
<Property name="amlbcookie" value="01"></Property>
<Property name="sun.am.UniversalIdentifier" value="id=upgradeuser,ou=user,dc=red,dc=iplanet,dc=com"></Property>
<Property name="Organization" value="dc=red,dc=iplanet,dc=com"></Property>
<Property name="Locale" value="en_US"></Property>
<Property name="HostName" value="xxx.yyy.aaa.bbb"></Property>
<Property name="com-iplanet-am-console-location-dn" value="dc=red,dc=iplanet,dc=com"></Property>
<Property name="AuthType" value="LDAP|anon1"></Property>
<Property name="UserProfile" value="Required"></Property>
<Property name="Host" value="xxx.yyy.aaa.bbb"></Property>
<Property name="clientType" value="genericHTML"></Property>
<Property name="AMCtxId" value="6747059ed30ea08a01"></Property>
<Property name="authInstant" value="2009-11-10T20:38:16Z"></Property>
<Property name="Principal" value="uid=upgradeuser,ou=people,dc=red,dc=iplanet,dc=com"></Property>
</Session>

And now here's Tones on Tail with a really wild video for Go! featuring many, many classic movie and animation clips that seem to dwell on the...um...tail. I saw Claudette Colbert, Elvis, Lorne Greene, Gary Cooper, John Wayne, Kathryn Grayson, Howard Keel, Betty Page (gulp!) and a roaring finale from Betty Boop. Who did you see?

Enjoy your turkey day all!

Monday Nov 16, 2009

Make REST Calls from OpenSSO Client SDK on the Video Phone

A new attribute has been added to the Advanced properties to support REST policy calls from the Client SDK to the new Entitlement Service. The com.sun.identity.policy.client.useRESTProtocol property is added to the Advanced -> Custom Properties section of the agent profile with a value of true to enable REST interface calls. If the property is not defined, the value defaults to false. Currently, this property is specific to J2EE agents as web agents do not use REST calls to get policy decisions.

So, yes, I planned to use the new Beyonce song Video Phone (see title) but something about this video (featuring Lady Gaga) is - how shall I say - ridiculous? No music, no melody, no thing - just videeeoooo phone and the same dance moves we've seen in every other Beyonce video. So rather than embedding that trash, here's Annie Golden (of The Shirts and Hair movie) singing Hang Up The Phone. Even in its blurry state this video has more class. And that's the truth.

Wednesday Nov 11, 2009

A Wonderful Use of Fedlet with Access Manager 7.1

Vimal P., Sun quality assurance engineer extraordinaire, has joined the blogosphere with his first post (well, second if you count the Hello, World test). Here's Vimal's one line description:

This blog describes how to setup the Single Sign On between Access Manager 7.1+ SAMLv2plugin acting as IDP and OpenSSO fedlet as SP.

So, jump from my part of the blogosphere world to Vimal's entry called How to Use Fedlet with Access Manager 7.1+ to learn how it's done. But first luxuriate in the sanguine tones of Louis Armstrong performing What A Wonderful World.

Tuesday Nov 10, 2009

Those Darlin' OpenSSO REST Policy Evaluation Interfaces

Piggybacking on the information in The OpenSSO REST Interfaces in Black / White, OpenSSO Express 9 will mark the release of the RESTful interfaces for policy evaluation. All of them support both HTTP GET and POST actions, and some of them return JavaScript Object Notation (JSON) objects. The format of the OpenSSO REST URL is:

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

NOTE: 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 information on invoking the available OpenSSO REST policy evaluation interfaces.

Evaluating a Decision for One Resource

The decision RESTful policy evaluation 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.

  • realm defines the realm in which the subject is defined. This is an optional parameter and the default value is /.
  • subject defines the value of the Universal ID attribute in the requesting user's OpenSSO profile.
  • action defines the action to be evaluated.
  • resource defines the resource to be evaluated.
  • application defines the requested service. This is an optional parameter and the default value is iPlanetAMWebAgentService.
  • env defines an optional environment map. This map may contain information such as the date and time or the IP address of the client. Examples might be env=requestIp%3D125.12.133.1 or env=requestTime%3D1248994000000.

For example:

http://OpenSSO-host:OpenSSO-port/opensso/ws/1/entitlement/decision?action=GET&resource=http://www.example.com/index.html&application=iPlanetAMWebAgentService&subject=uid=demo,ou=user,dc=opensso,dc=java,dc=net&env=requestTime%3D1248994000000

Evaluating a More Specific Decision for One Resource

The entitlement RESTful policy evaluation interface returns a list of JSONEntitlement objects in regards to a request for access to a resource. Although similar to the decision interface, it does allow more information to be returned as a JSON privilege object. The URL may be populated with the following information.

  • realm defines the realm in which the subject is defined. This is an optional parameter and the default value is /.
  • subject defines the value of the Universal ID attribute in the requesting user's OpenSSO profile.
  • resource defines the resource to be evaluated.
  • application defines the requested service. This is an optional parameter and the default value is iPlanetAMWebAgentService.
  • env defines an optional environment map. This map may contain information such as the date and time or the IP address of the client. Examples might be env=requestIp%3D125.12.133.1 or env=requestTime%3D1248994000000.

For example:

http://OpenSSO-host:OpenSSO-port/opensso/ws/1/entitlement/entitlement?resource=http://www.example.com&application=iPlanetAMWebAgentService&subject=uid%3Ddemo,ou%3Duser,dc%3Dopensso,dc%3Djava,dc%3Dnet

The following result signifies that the evaluation has approved the request for access. But, demo does not have access permission to http://www.example.com because the IP address does not fall within the range of 192.122.18.1 and 192.122.18.254.
{
   "statusCode":200,
   "statusMessage":"OK",
   "body":{
       "results":[
       {
          "actionsValues":{
          },
          "attributes":{},
          "advices":{
               "com.sun.identity.entitlement.IPCondition": "[
                    \\"requestIp=192.122.18.1-192.122.18.254\\"
               ]"
          },
          "resourceName":"http://www.example.com"
       }
   }
}

Evaluating a Decision for Multiple Resources

The decisions RESTful policy evaluation 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.

  • realm defines the realm in which the subject is defined. This is an optional parameter and the default value is /.
  • subject defines the value of the Universal ID attribute in the requesting user's OpenSSO profile.
  • resources defines the set of resources to be evaluated. More than one resources parameter may be added to the URL.
  • application defines the (application or application type). This is an optional parameter and the default value is iPlanetAMWebAgentService.
  • env defines an optional environment map. This map may contain information such as the date and time or the IP address of the client. Examples might be env=requestIp%3D125.12.133.1 or env=requestTime%3D1248994000000.

For example:

http://OpenSSO-host:OpenSSO-port/opensso/ws/1/entitlement/decision?resources=http%3A//www.example.com/index.html&resources=http%3A//www.example2.com/index.html&application=iPlanetAMWebAgentService&subject=uid%3Ddemo,ou%3Duser,dc%3Dopensso,dc%3Djava,dc%3Dnet

The following result signifies that the evaluation has approved the request for access. Additionally, demo (the OpenSSO demo user) has POST and GET permission for http://www.example.com and GET permission for http://www.example2.com.
{
   "statusCode":200,
   "statusMessage":"OK",
   "body":{
       "results":[
       {
          "actionsValues":{
             "POST":true,
             "GET":true
          },
          "attributes":{},
          "advices":{},
          "resourceName":"http://www.example.com"
       }
       {
          "actionsValues":{
             "GET":true
          },
          "attributes":{},
          "advices":{},
          "resourceName":"http://www.example2.com"
       }
       ]
   }
}

Evaluating a Decision for A Root and Sub Tree Resources

The entitlements RESTful policy evaluation interface returns a list in the form of a JSONEntitlements object in regards to a request for access to root resource and its (multiple) sub resources. 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.

  • realm defines the realm in which the subject is defined. This is an optional parameter and the default value is /.
  • subject defines the value of the Universal ID attribute in the requesting user's OpenSSO profile.
  • resource defines the root of the set of resources to be evaluated.
  • application defines the requested service. This is an optional parameter and the default value is iPlanetAMWebAgentService.
  • env defines an optional environment map. This map may contain information such as the date and time or the IP address of the client. Examples might be env=requestIp%3D125.12.133.1 or env=requestTime%3D1248994000000.

For example:

http://OpenSSO-host:OpenSSO-port/opensso/ws/1/entitlement/entitlement?resources=http://www.example.com&application=iPlanetAMWebAgentService&subject=uid=demo,ou=user,dc=opensso,dc=java,dc=net&env=requestTime%3D1248994000000

The following result signifies that the evaluation has approved the request for access. But, demo (the OpenSSO demo user) has POST and GET permission only for http://www.example.com/hr/\* and http://www.example.com/engr/\*.
{
   "statusCode":200,
   "statusMessage":"OK",
   "body":{
       "results":[
       {
          "actionsValues":{
          },
          "attributes":{},
          "advices":{},
          "resourceName":"http://www.example.com"
       }
       {
          "actionsValues":{
             "POST":true
             "GET":true
          },
          "attributes":{},
          "advices":{},
          "resourceName":"http://www.example.com/hr/\*"
       }
       {
          "actionsValues":{
             "POST":true
             "GET":true
          },
          "attributes":{},
          "advices":{},
          "resourceName":"http://www.example.com/engr/\*"
       }
       {
          "actionsValues":{
          },
          "attributes":{},
          "advices":{
               "com.sun.identity.entitlement.IPCondition": "[
                    \\"requestIp=192.122.18.1-192.122.18.254\\"
               ]"
          },
          "resourceName":"http://www.example.com/sales/\*"
       }
   }
}

Now enjoy the musical and illustrative (?) accomplishments of Those Darlins with Red Light Love. It's dope. And that's a good thing!

Thursday Nov 05, 2009

Harden OpenSSO By Disabling ssoadm.jsp

Notwithstanding that it is still a secret, we've just added a property that allows you to disable the ssoadm.jsp to harden your system and reduce attack vectors. The property is ssoadm.disabled and can be added with a value of true to the Advanced properties.

  1. Log into the OpenSSO console as administrator.
  2. Click the Configuration tab.
  3. Click the Servers and Sites tab.
  4. Click the Server name in the Servers table.
  5. Click the Advanced tab.
  6. Click Add in the Advanced Properties table.
  7. Enter ssoadm.disabled as the Property Name and true as the Property Value.
  8. Click Save.

You can also add this property as a default setting for future server configurations by clicking the Default Server Settings button under the Servers and Sites tab.

And now here's the only song that I know of that uses the word harden. The video is a live performance of Quarterflash singing (and playing saxophone on) Harden My Heart.

Monday Nov 02, 2009

Switch On Switch Off OpenSSO SAMLv2 Services

Currently, the SAMLv2 Service servlets are always listening. For example, if you don't want to use the Artifact Resolution Service or the Manage Name ID Service it is still on. To switch the services off, you can remove the endpoints from the entity provider's configuration.
  1. Log into the OpenSSO console as administrator.
  2. Click the Federation tab.
  3. Click the name of the entity provider for which you want switch off a particular SAMLv2 Service.
  4. Click the Services tab.
  5. Remove the appropriate endpoint.
  6. Click Save.
You can also use the ssoadm command line interface.
  1. Use ssoadm export-entity to export the extended metadata.
  2. Modify the exported extended metadata.
  3. Use ssoadm delete-entity to delete the original extended metadata.
  4. Use ssoadm import-entity to import the modified extended metadata.
Disabled services return an HTTP error code.

Interestingly enough, after I titled this entry using the B-Movie single Switch On Switch Off, I was unable to find a video for that song anywhere. (It was a failed single but really this IS the internet.) In absentia, here is B-Movie's biggest hit (of which there are plenty of videos) Nowhere Girl.

3743

Tuesday Oct 20, 2009

Someone Needs a ヴァケイション

Someone (who shall remain nameless) did the unthinkable and changed the status of the / Top Level Realm to inactive. After doing this, someone could no longer log in to the console. So how did someone rectify this situation?

Someone used an LDAP browser, found the ou=services,dc=opensso,dc=java,dc=net field and changed the value back. Now remember...don't actually do this but at least there is a way to undo it.

And now here's Connie Francis singing her hit Vacation in Japanese. Who knew?

Tuesday Oct 13, 2009

Cool Changes to the OpenSSO Console

Some new attributes have been added to the OpenSSO Administration Console and are available now in the nightly builds.
  1. Prompt User for Old Password is a flag that will do just that - add a text field to the Change Password page that would require a user to enter the old password when changing it. The attribute is located under the top level Configuration tab. Underneath the Configuration tab, click the Console tab and then the Administration link. It is in the Realm Attributes section.
    If not checked, the old password will not be required. This is the default behavior. If checked, the behavior is dependent upon whom is changing the password: the administrator or the end user.

    • If an administrator is changing the password for the end user, the old password is not required. The Prompt User for Old Password text field will be grayed out and the password will be changed by calling the getIdentity method in com.sun.identity.idm.IdUtils.
    • If the end user is changing the password on their own, the old password will be required. The Prompt User for Old Password text field will be enabled and, after it has been entered, the password will be changed by calling the changePasswordmethod in com.sun.identity.idm.AMIdentity.
  2. Requested Key Type allows you to define the key system used by the STS Client profile defined; for example, the default SecurityTokenService. The attribute is located under the top level Access Control tab. Under the Access Control tab, click the appropriate realm link, then the Agents tab and then the STS Client tab. Click the name of the profile you are configuring to see the attribute under the Security section.
    You can choose Public Key (two keys are used - one to encrypt the data and one to decrypt the data) or Symmetric Key (one key is used to encrypt and decrypt the data).
  3. A SAML Configuration section has been added to the STS Client and Web Service Client agent profiles to help configure the SAMLv2 protocol. (The section already exists for the Web Service Provider agent profile.) The section is located under the top level Access Control tab. Under the Access Control tab, click the appropriate realm link, then the Agents tab and then the STS Client tab or the Web Service Client tab. Click the name of the profile you are configuring to see the SAML Configuration section link. The section includes the following attributes.

    • SAML Attribute Mapping: This configuration maps the SAML attribute in an assertion from an incoming web service request to an attribute that would be fetched from either an authenticated OpenSSO SSOToken or the configured OpenSSO identity data store. The SAML attribute would be placed in the Attribute Statement created by the Security Token Service for a web service provider. The format is SAML_attr_name=OSSO_attr_name where SAML_attr_name is the SAML attribute name in the assertion from an incoming web service request and OSSO_attr_name is the attribute name that is fetched from OpenSSO.
    • SAML NameID Mapper Plugin: This attribute defines the NameID mapper plug-in class to be used for SAML account mapping.
    • SAML Attributes Namespace: This attribute defines the name space used to qualify SAML attributes and elements.
    • Include Memberships: If enabled, this attribute specifies that the principal's membership data must be included in the assertion as a SAML attribute.

Now here's Cool Change from Little River Band.

Thursday Oct 08, 2009

The OpenSSO REST Interfaces in Black / White

A RESTful web service assumes all components are exposed using the same, uniform application interface. (An interesting article on other requirements of REST can be read here.) From this high-level HTTP accomplishes this uniformity with its methods such as GET and POST. Thus calling a RESTful web service requires the simple construction of a URL.

OpenSSO exposes a number of interfaces that support a REST architecture. These operations are supported out of the box so no special configurations are required. The format of the URL is:

http://OpenSSO-host:OpenSSO-port/opensso/identity/OpenSSO-REST-interface?parameter1=value1&parameter2=value2&parameterN=valueN

NOTE: 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 information on invoking the available OpenSSO REST interfaces.

Authentication

The authenticate REST interface opens an HTTP connection to authenticate a user with a POST operation. The following URL defines a username and password that will be authenticated at the OpenSSO root realm - by default, / (Top Level Realm).

http://OpenSSO-host:OpenSSO-port/opensso/identity/authenticate?username=jning&password=pwjning

You can also add the optional uri parameter to the URL. The value of this parameter would be one or more of the URL parameters documented in Accessing the OpenSSO Enterprise Authentication Service User Interface with a Login URL. For example, the following URL will authenticate the user to a specific sub realm.

http://OpenSSO-host:OpenSSO-port/opensso/identity/authenticate?username=jning&password=pwjning&uri=realm=sub_realm_name

You can define additional parameters. For example, the following URL will authenticate the user to a specific sub realm using the specified authentication chain (ldapService, for example).

http://OpenSSO-host:OpenSSO-port/opensso/identity/authenticate?username=jning&password=pwjning&uri=realm=sub_realm_name&service=ldapService

After successful authentication, a token string is returned to represent the authenticated user for other REST operations. Various exceptions might also be thrown such as UserNotFound and InvalidPassword. A generic exception is provided if unable to reach OpenSSO or for other fatal errors.

NOTE: The token string returned is also applied as the value of the subjectid in some OpenSSO REST operations like logout and authorize.

Token Validation

The isTokenValid REST interface validates the token using the POST operation. The following URL defines a tokenid that will be validated by OpenSSO.

http://OpenSSO-host:OpenSSO-port/opensso/identity/isTokenValid?tokenid=AQIC5wM2LY4SfczeSHZ5cHJMmQYU3f5imB2fBBTpkCXADS0=-AT-AAJTSQACMDE=#

The operation returns a value of true or false.

Logout

The logout REST interface validates the token using the POST operation. The following URL defines a tokenid that will be validated by OpenSSO.

http://OpenSSO-host:OpenSSO-port/opensso/identity/logout?subjectid=AQIC5wM2LY4SfczeSHZ5cHJMmQYU3f5imB2fBBTpkCXADS0=-AT-AAJTSQACMDE=#

The operation invalidates the tokenid and logs the user out.

Authorization

The authorize REST interface will verify against created policies that the user is authorized to perform a particular operation (GET or POST) on a particular HTTP resource. The following URL defines a user (subjectid) that wants to POST (action) to the specified resource (uri).

http://OpenSSO-host:OpenSSO-port/opensso/identity/authorize?uri=http://www.sun.com:90&action=POST&subjectid=AQIC5wM2LY4SfczeSHZ5cHJMmQYU3f5imB2fBBTpkCXADS0=@AAJTSQACMDE=#

The operation returns a value of true or false. If the user is not authorized, an exception is thrown. Assuming a policy has been created to allow authenticated users to POST to the defined resource (in this case, http://www.sun.com:90), the above URL would return true.

Logging

The log REST interface will log to the OpenSSO Logging Service. The URL needs to be populated with the following information.
  • appid defines the tokenid of the user with the necessary permissions to write to the log; for example amadmin.
  • subjectid defines the tokenid of the user about whom the log record is being written.
  • logname is the module name of the OpenSSO component invoking the Logging Service; for example, amAuthentication.
  • message is the data being logged.

An example URL is:

http://OpenSSO-host:OpenSSO-port/opensso/identity/log?appid=AQIC5wM2LY4Sfcz24GvZCdv6ie9dTJBa3Co7Rn2QUjKCDuM=@AAJTSQACMDE=#&subjectid=AQIC5wM2LY4SfcwTCcRKSDXEsiJXt71PDAUmN1bm/draPZI=@AAJTSQACMDE=#&logname=amAuthentication&message=test

Searching Identity Types

The search REST interface will search the configured database for particular identities. The URL needs to be populated with the following information.
  • filter defines a set of criteria that controls what is returned by the operation.
  • attributes_name defines one or more LDAP attributes for which to search.
  • attribute_values_value-of-attributes_name defines the value of the attribute (defined by attributes_name) that is being searched.
  • admin defines the tokenid of the user with the necessary permissions to search; for example amadmin.

The following URL would return the available agent types; by default string=wsc, string=wsp, and string=SecurityTokenService.

http://OpenSSO-host:OpenSSO-port/opensso/identity/search?filter=\*&attributes_names=objecttype&attributes_values_objecttype=agent&admin=AQIC5wM2LY4SfcxCWBCNON1gTsaMaHISbYmTyYosv8pCPVw=@AAJTSQACMDE=#

This example would return all user entries.

http://OpenSSO-host:OpenSSO-port/opensso/identity/search?filter=\*&attributes_names=objectclass&attributes_values_objectclass=person&admin=AQIC5wM2LY4SfcxCWBCNON1gTsaMaHISbYmTyYosv8pCPVw=@AAJTSQACMDE=#

Display Identity Data

The attributes REST interface will search the configured database for identity information about the defined subjectid. It retrieves roles and common attributes (including first name and last name) and is used by applications to obtain a user's profile for application-controlled authorization. Optionally, the URL can take one or more attribute_names parameters to define which attribute values will be returned; if attribute_names is not defined it would return all the attributes in the profile. This is an example URL that would return the specified user's LDAP profile.

http://OpenSSO-host:OpenSSO-port/opensso/identity/attributes?attributes_names=uid&subjectid=AQIC5wM2LY4Sfcz6eH4abOQ0el7pnDqmOn6nnn1nrcuE8/w=@AAJTSQACMDE=#

The URL might return something like this:
userdetails.token.id=AQIC5wM2LY4Sfcz6eH4abOQ0el7pnDqmOn6nnn1nrcuE8/w=@AAJTSQACMDE=#
userdetails.attribute.name=sn
userdetails.attribute.value=jning
userdetails.attribute.name=cn
userdetails.attribute.value=jning
userdetails.attribute.name=objectclass
userdetails.attribute.value=sunFederationManagerDataStore
userdetails.attribute.value=top
userdetails.attribute.value=iplanet-am-managed-person
userdetails.attribute.value=iplanet-am-user-service
userdetails.attribute.value=organizationalperson
userdetails.attribute.value=inetadmin
userdetails.attribute.value=iPlanetPreferences
userdetails.attribute.value=person
userdetails.attribute.value=inetuser
userdetails.attribute.value=sunAMAuthAccountLockout
userdetails.attribute.value=sunIdentityServerLibertyPPService
userdetails.attribute.value=inetorgperson
userdetails.attribute.value=sunFMSAML2NameIdentifier
userdetails.attribute.name=userpassword
userdetails.attribute.value={SSHA}XhiE0RMwO/D7SSQ5fYLrTlFjmbHmYbQkIU43FA==
userdetails.attribute.name=uid
userdetails.attribute.value=jning
userdetails.attribute.name=givenname
userdetails.attribute.value=jning
userdetails.attribute.name=inetuserstatus
userdetails.attribute.value=Active

Display Particular Identity Data

The read REST interface will search the configured database for particular identity information about the LDAP user defined by name. The attributes_names parameter defines one or more LDAP attributes for which to search. This is an example URL that would return the specified user's LDAP profile.

http://OpenSSO-host:OpenSSO-port/opensso/identity/read?name=jning&attributes_names=uid&admin=AQIC5wM2LY4SfcxCWBCNON1gTsaMaHISbYmTyYosv8pCPVw=@AAJTSQACMDE=#

The URL might return something like this:
identitydetails.name=jning
identitydetails.type=user
identitydetails.realm=dc=opensso,dc=java,dc=net
identitydetails.attribute=
identitydetails.attribute.name=uid
identitydetails.attribute.value=jning

Creating Identity Types

The create REST interface will create the defined identity type in the configured data store. The URL needs to be populated with the following information. Note the values for these parameters in the sample URLs below.
  • identity_name defines a easily-readable name for the identity.
  • identity_attribute_names defines one or more LDAP attributes to be created for the identity.
  • identity_attribute_values_value-of-identity_attribute_names defines the value of the attribute (defined by attributes_name) being created.
  • identity_realm defines the realm in which the identity is created.
  • identity_type defines the type of identity being created.
  • admin defines the tokenid of the user with the necessary permissions to create; for example amadmin.

This URL would create a user type. Use the search REST interface to verify its creation.

http://OpenSSO-host:OpenSSO-port/opensso/identity/create?identity_name=rest_user&identity_attribute_names=userpassword&identity_attribute_values_userpassword=secret123&identity_attribute_names=sn&identity_attribute_values_sn=sn_of_rest_user&identity_attribute_names=cn&identity_attribute_values_cn=cn_of_rest_user&identity_realm=/&identity_type=user&admin=AQIC5wM2LY4Sfcwbg2YdVMaYsfEqdxHDMUc47WSLBNTOlrk=@AAJTSQACMDE=#

The following URL would create a web agent profile for Policy Agent 3.0 types. Use the search REST interface to verify its creation.

http://OpenSSO-host:OpenSSO-port/opensso/identity/create?&identity_name=webagent&identity_realm=/&identity_type=AgentOnly&identity_attribute_names=userpassword&identity_attribute_values_userpassword=secret123&identity_attribute_names=AgentType&identity_attribute_values_AgentType=WebAgent&identity_attribute_names=SERVERURL&identity_attribute_values_SERVERURL=http://web-agent-host:web-agent-port/opensso

The following URL would create a J2EE agent profile for Policy Agent 3.0 types. Use the search REST interface to verify its creation.

http://OpenSSO-host:OpenSSO-port/opensso/identity/create?&identity_name=j2eeagent&identity_realm=/&identity_type=AgentOnly&identity_attribute_names=userpassword&identity_attribute_values_userpassword=secret123&identity_attribute_names=AgentType&identity_attribute_values_AgentType=J2EEAgent&identity_attribute_names=SERVERURL&identity_attribute_values_SERVERURL=http://J2EE-agent-host:J2EE-agent-port/opensso&identity_attribute_names=AGENTURL&identity_attribute_values_AGENTURL=http://OpenSSO-host:OpenSSO-port/opensso

The following URL would create a 2.2 agent profile. Use the search REST interface to verify its creation.

http://OpenSSO-host:OpenSSO-port/opensso/identity/create?identity_name=webagent70&identity_attribute_names=userpassword&identity_attribute_values_userpassword=secret123&identity_realm=/&identity_type=Agent&admin=AQIC5wM2LY4Sfcwbg2YdVMaYsfEqdxHDMUc47WSLBNTOlrk=@AAJTSQACMDE=#

Updating Identity Data

The update REST interface will update an identity with the information defined in the URL. The following URL would update the user profile with an email address.

http://OpenSSO-host:OpenSSO-port/opensso/identity/update?identity_name=rest_user&identity_attribute_names=mail&identity_attribute_values_mail=restUser@rest-DOT-org&admin=AQIC5wM2LY4Sfcwbg2YdVMaYsfEqdxHDMUc47WSLBNTOlrk=@AAJTSQACMDE=#

Use the read REST interface to verify the update.

Deleting an Identity Profile

The delete REST interface will remove the identity profile (defined as the value of the identity_name parameter) from the user data store. The following URL would delete the rest_user profile previously created.

http://OpenSSO-host:OpenSSO-port/opensso/identity/delete?identity_name=rest_user&admin=AQIC5wM2LY4Sfcwbg2YdVMaYsfEqdxHDMUc47WSLBNTOlrk=@AAJTSQACMDE=#&identity_type=user

Use the search REST interface to verify the deletion.

Now check out the not-most-recent-single-but-still-great-video from The Raveonettes: Black / White.

Thursday Sep 17, 2009

Agents Belong with OpenSSO and Reverse Proxy

If your OpenSSO deployment architecture includes a reverse proxy server, you have the option of protecting the content servers by installing a policy agent on the proxy itself, or installing multiple policy agents on the content servers behind the reverse proxy server. The choice is dependent on the relative uniformity or variability of the hosted/protected content and the access-denied URLs.

NOTE: A reverse proxy server or a load balancer with a reverse proxy feature is usually installed between the outer firewall and the inner firewall - in the demilitarized zone (DMZ) between the internet and the secure intranet.

Using a Single Agent

When there is a uniformity in the configuration of the content servers in the back-end (including access denied URLs, application logout URLs, profile, session and response attributes, and the web container type), a single policy agent for the reverse proxy server would be the efficient way of protecting the content. The following diagram illustrates this.

Regardless of the number of content servers being fronted by the reverse proxy, only one agent is installed on the reverse proxy machine. The footprint of this configuration is less cost (fewer agents to maintain) and less memory (a single agent requires less memory to cache). With one agent no communication will occur between the content servers and the OpenSSO server. The policy agent will have back channel communications with the OpenSSO load balancer to update cache entries, perform session validation, and make policy requests but, since the agent is installed on the reverse proxy server and not on the content servers, only the reverse proxy server would communicate with the OpenSSO load balancer. This effectively reduces the number of communication channels which would result in fewer firewall rules, tighter control over server-to-server communications, and a higher level of security.

Using Multiple Agents

When a number of content servers use different types of web containers or each content server has different access denied URLs, agent profiles, session and response attributes, and application logout URLs, the only choice is to install multiple policy agents. Each agent will have its own customized agent profile.

Unlike in the case of the single reverse proxy server policy agent where the same session identifier is used to access many applications protected by the agent, multiple policy agents do not use the same session identifier (when the agents are configured in cookie hijacking prevention mode). With multiple agents, it is now easy to customize agent properties per content server; for example, customize profile attributes to be fetched, session attributes to be fetched, response attributes to be added to the header, URL of the access denied page, customized application error pages, and application logout URLs. (By customizing each application's logout URL, it is possible to perform cleanup tasks (destroying the user's session or resetting cookies) per application.

See the following links for more information.

Piggybacking on the music videos from Accessing OpenSSO from Outside a Secure Intranet (Put a Lock On It), here's the Taylor Swift video that won the VMA - against Kanye's better wishes.

Friday Sep 04, 2009

OpenSSO Express 8 Shall Be Released

Congratulations to all on the release of OpenSSO Express 8, an early access version of Sun OpenSSO Enterprise that is fully supported and indemnified by Sun Microsystems for customers. The new ZIP archive is available for download on opensso.dev.java.net.

OpenSSO Express 8 introduces:
  • One Time Password Authentication
  • A new Resource Authentication Type
  • Federated single sign-on for .Net applications using the .NET Fedlet
  • Support for MySQL as a user data store
  • The new Entitlements Service
  • A new monitoring framework built using the Java Dynamic Management Kit (JDMK)
  • A new Administration Console (in beta) that allows authorization administration with the new Entitlements Service and new work flows for configuring federation and web services security
  • A new work flow for setting up federated single sign-on with Salesforce.COM
A list of all the new features and enhancements in OpenSSO Express 8 is available as part of Release Notes. Detailed documentation on the new features is available on the OpenSSO Documentation wiki.

And here's an incredible (and incredibly old) performance of Bette Midler singing Bob Dylan's I Shall Be Released.

Monday Aug 24, 2009

Breakaway from the Policy Service with OpenSSO Entitlements

Appropos to Dennis's announcement of the Entitlements Service source code being moved into the OpenSSO workspace, here's some information about the developing OpenSSO Entitlements Service.

The Entitlements Service is an authorization and policy component developed for inclusion in the soon-to-be-released OpenSSO Express 8. The user interface provides an easy-to-follow process to define rules for controlling access to applications and web resources. You can create fine-grained policies, and referrals (to assign policy creation based on an OpenSSO realm hierarchy), using these work flows.

The Entitlements Service is being developed in tandem with a new beta OpenSSO administration console. The OpenSSO Enterprise Policy Service, used for more coarse-grained policy implementation, is still available using the standard OpenSSO administration console. See The New OpenSSO Console Rip-Off.

From a high level a service used to create and manage access to web resources consists of the following:
  • A policy administration point (PAP) that comprises the interfaces used to create, read, update and delete the policies.
  • A policy evaluation engine or policy decision point (PDP) that, acting as a policy information point (PIP), is used to query permissions and privileges in order to obtain policy decisions. It gets identity attributes and applicable policies, evaluates the information, and returns the latter with a policy decision to be used for enforcement.
  • A policy enforcement point (PEP) is an agent, installed on the same machine as the resource, that protects it from unauthorized access.
  • A user data store for storing and obtaining identity data.
  • A policy data store for storing policies and the service's configuration attributes, and obtaining said data. (OpenSSO embeds OpenDS for its configuration data store. This configuration data store is used to store Entitlements Service data.)

Different types of resources can be protected by the Entitlements Service. By selecting a general application and adding a more specific resource with applicable subjects and conditions, a policy can be created to define authorization using the new beta console administration interface. An application (term as used in the Entitlements Service) consolidates meta data for generic resource types that share a common set of actions. The format of a resource's definition, supported actions, conditions and subjects, decision combining algorithms (to resolve conflicting policy results) and other data can be defined as a schema for an application. Examples of applications in the Entitlements Service could be calendars, web resources, or user profiles. The following applications are added by default when deploying opensso.war.
  • Web Agent defines actions that can be used to create and manage policies that protect HTTP and HTTPS URLs through the use of a policy agent. This is the most common application use case with the following actions.
    • GET has these operations.
      • Allow: Enables access to the resource defined in the Rule.
      • Deny: Denies access to the resource defined in the Rule.
    • POST has these operations.
      • Allow: Enables access to the resource defined in the Rule.
      • Deny: Denies access to the resource defined in the Rule.
  • Liberty Personal Profile allows administrators to create and manage policies corresponding to actions that can be performed on identity attributes in a personal profile service defined by the Liberty Alliance Project specifications; for example, the OpenSSO implementation of the Liberty Personal Profile Service.
    • MODIFY has these operations.
      • Interact for Value: Invokes the Liberty Alliance Project ID-WSF Interaction Service Specification protocol to retrieve a value from a resource in order to modify it.
      • Interact for Consent: Invokes the Liberty Alliance Project ID-WSF Interaction Service Specification protocol for consent to modify a value on a resource.
      • Allow: Enables access to the resource defined in the Rule in order to modify an attribute value.
      • Deny: Denies access to the resource defined in the Rule therefore modification is disallowed.
    • QUERY has these operations.
      • Interact for Value: Invokes the Liberty Alliance Project ID-WSF Interaction Service Specification protocol to retrieve a value from a resource.
      • Interact for Consent: Invokes the Liberty Alliance Project ID-WSF Interaction Service Specification protocol for consent to query a resource.
      • Allow: Enables access to the resource defined in the Rule in order to query the resource.
      • Deny: Denies access to the resource defined in the Rule therefore the query is disallowed.
  • Discovery Service allows administrators to create and manage policies corresponding to actions that can dynamically determine a web services provider (WSP) registered for a particular principal.
    • LOOKUP: Allow or Deny access to search the discovery service.
    • UPDATE: Allow or Deny access to modify data in the discovery service.
A resource is an object on which you can perform an operation or an action. The policy is specifically configured to protect this object. A resource is a string; it could be a URL, a web service, a bank account, or graphical user interface controls (buttons, text fields and the like). Examples could be MyCalendar or other portal type services (located with URLs), a bank account, or a Submit button on a text form.

More information on the Entitlements Service will be forthcoming; these definitions should help you get started, in a small way, by following the inline help developed for the Entitlements Service GUI. But first - enjoy Tracey Ullman singing Breakaway into her hairbrush.

Friday Aug 14, 2009

The New OpenSSO Console Rip-Off

OK, it's not technically a rip-off but that's all I could come up with in the time allotted.

The team of OpenSSO engineers have been working on a new administration console. The plan is to release a beta version of the new console with OpenSSO Express Build 8. Although the trees that contribute to the nightly build and the Express 8 build have not yet been consolidated, portions of the new beta console are available for your perusal in the nightly build. Things will undoubtedly change before the actual release; the following information is so you can take a look at the direction we are going.

This new OpenSSO administration console is in beta and should only be used for test environments. Continue to use the standard OpenSSO administration console for real-time deployments.

After deploying opensso.war to a web container, login to OpenSSO as the administrator and enter protocol://machine.domain:port/deploy-uri/admin in the Location Bar of a browser to display the new console interface.

The Entitlements, Federation and Web Service Security tabs comprise the bulk of features currently in this new console. Accommodations have been made for these features by providing inline help displayed on the console screen. Additional documentation will be available after the beta release. Working With the Entitlements Service The Entitlements tab contains the new work flows for ease-of-use when creating new, and managing existing, policies for the new Entitlements Service. These features are only available in the beta administration console. You must choose the framework with which you will be creating policies for your resources. The options are the Policy Service using the standard administration console and the Entitlements Service using the beta administration console. Once the choice is made (by creating and saving a policy using one or the other), only that service (Entitlements or Policy) will be enabled. Migration of policies from previous versions of OpenSSO is not supported.

Using the Federation Work Flows The Federation tab contains the new work flows for ease-of-use when creating and registering entity providers for the Federation Service using the SAMLv2 protocol. These work flows are available in either the standard or beta administration console. If you create SAMLv2 entity providers using the work flows in the beta administration console, you manage the configurations using the standard administration console.

Using the Web Services Security Work Flows The Web Service Security tab contains the new work flows for ease-of-use in creating profiles to work with the Web Service Security framework. These work flows are available only in the beta administration console although profiles can also be created by manually configuring attributes using the standard administration console. You can create profiles in the beta console and manage them in the standard console.

Displaying Realms The intent with the beta administration console is to hide realms. If no realms are configured using the standard console, the applicable interface to switch realms will not be visible in the beta console, nor anything about referrals. If you create a realm using the standard console, realm and referral menu items are visible.

Now enjoy the greatly, soulful Laura Lee and her 1972 hit, Rip-Off.


Wednesday Jul 29, 2009

OpenSSO's Secret Place

Look in the OpenSSO-Deploy-Base\*/opensso directory and you'll find ssoadm.jsp. This best kept secret is the web version of the ssoadm command line interface and can be used as such - although it's technically a secret. So check it out but don't tell them I sent you.

And now listen to Joni Mitchell and Peter Gabriel singing My Secret Place.

\* OpenSSO-Deploy-Base represents the directory in which your particular web container deploys the opensso.war.

Tuesday Jul 07, 2009

OpenSSO Under Replay Attacks

A replay attack occurs when a valid data transmission is maliciously intercepted and retransmitted. Digital signatures alone do not provide protection against replay attacks in web services communications as a signed message can still be recorded and resent. The WS-Security specification recommends a number of options to protect against replay attacks; from those options, the OpenSSO web services framework has implemented the use of the time stamp. That said, here is some preliminary information about preventing replay attacks using OpenSSO.
More to come. Below is subject to tweak. But you got it first.
The OpenSSO web services security framework is driven primarily by security agents that install on deployed web containers remote to OpenSSO. The security agent accesses the web services security framework using the SOAPRequestHandler interface in the Client SDK to validate SOAP messages and authenticate against OpenSSO. As part of the process, digital signatures and encryptions are validated and, following that, the message's time stamp is processed to check for replay attacks. The time stamp can be processed using either of the following options.
  • MessageID
    The WS-Addressing MessageID header can be optionally included in a SOAP message. The value of the MessageID from a first request is cached. The messageIDMap cache uses the MessageID value to index the local time stamp (stamped when the message is received). Any message requests that use the same MessageID and are found to be within a configured time interval will be treated as a duplicate and will be rejected. (If a MessageID is not found in the incoming SOAP request, the authenticated subject identifier is used to index the time stamp.)
  • nonce
    If implementing the Username Token profile for web services security, you can cache the cryptographically random value of the nonce element from each initial request. The messageIDMap cache uses the nonce value to index the creation time stamp (time at which the token was generated). Any message requests that use the same nonce and are found to be within a configured time interval will be treated as a duplicate and will be rejected.

The Client SDK can not use the high availability and failover features of OpenSSO. Thus, the solution is to provide an interface to use for persistent storage of the state of the cache on the web services provider side. The com.sun.identity.wss.security.handler.WSSCacheRepository interface assumes a repository has already been configured and the cache can be persistently stored in it. There is no out of the box implementation for this interface but the name of the implementation class, if developed, needs to be entered as the value of the com.sun.identity.wss.security.cacherepository.plugin attribute in the AMClient.properties file. To enable the replay attack prevention feature, you create a web services provider agent profile under the appropriate realm. Once the profile has been created, follow this procedure.
  1. Click the name of the realm in which the agent profile was created.
  2. Click the Agents tab.
  3. Click the Web Service Provider tab.
  4. Click the name of the appropriate web service provider profile.
  5. Enable Detect Message Replay if applicable.
    This enables the MessageID option.
  6. Enable Detect User Token Replay if applicable.
    This enables the nonce option.
  7. Save the configuration.
You also need to add the web service client instance of OpenSSO and the Security Token Service instance of OpenSSO as a value in the Trusted Server listing. The cache is cleaned up using a periodic cleanup thread with a configurable time interval.

And now ABBA, a group that knows something about being Under Attack.

Thursday Jun 18, 2009

Moving OpenSSO Session Cookie Hijacking Information

In reorganizing and rewriting the OpenSSO Enterprise 8.0 Administration Guide, I thought the chapter on session cookie hijacking was in the wrong place. The Administration Guide is a guide for administering and configuring OpenSSO Enterprise using the console and the command line. The information in the session cookie hijacking chapter, with its emphasis on a technical overview, security issues and configuration seemed more inline with a task that would be done post OpenSSO installation and deployment. Thus the chapter was moved, intact, to the OpenSSO Enterprise 8.0 Installation and Configuration Guide.

So, if looking for information on session cookie hijacking, check out Chapter 19, Taking Precautions Against Session-Cookie Hijacking in an OpenSSO Enterprise Deployment in the aforementioned ICG.

And speaking of moving, here's Kate Bush, live at the Hammersmith Odeon, with the first cut from The Kick Inside, Moving.

Move over, Madonna. THIS was the first time I had seen anyone use the telephone operator microphone in a live performance.

Tuesday Apr 28, 2009

Sweet Soul Revue-ing 'Organizing Data in an OpenSSO Realm'

Notwithstanding Maybe You'll Know: Logging in to the OpenSSO Console, here's another chapter from the Sun OpenSSO Enterprise 8.0 Administration Guide that has been rewritten and wiki-ized.

Organizing Data in a Realm basically takes you through the tabs that are used to configure data in a realm - everything under the Access Control tab. The simpler sections are complete in this entry while the more complex sections link to chapters on docs.sun.com (until these chapters are also formatted for wiki).

So what's missing? Is the information organized as you might look for it when using the console? When you read a section are you wanting further information for which there is no link? Remember this is administration information when you read it - not coding or customization.

Thoughts? Comment here or on the wiki.

Coming up: Managing Authentication Using Realms

Sweet Soul Revue is a great pop song from the Japanese band, Pizzicato Five. I had a bunch of P5 albums in the 90s although I never quite knew what most of the lyrics were about. Still got me up on the dance floor!

Monday Apr 20, 2009

Creating an OpenSSO User Data Store Using Sun Directory Server is Like Riding a Bicycle

My instance of OpenSSO Enterprise Express Build 7 was installed with the option to use the embedded data store as a user data store. This option is for proof-of-concepts only and should not be used in real-time deployments. I wanted to check out some stuff regarding roles and, as the roles portion of OpenSSO only works with an installed Sun Directory Server, I installed Directory Server EE 6.3.

If you haven't installed OpenSSO yet, check out OpenSSO Build 2 and Glassfish: Ready to Go. It's an older entry but still works - despite the old screen shots. Once complete, proceed with the following tasks.
  1. Make a directory named ds.
  2. Download Directory Server Enterprise Edition (EE) 6.3 into the ds directory.
  3. Decompress the file.
    gunzip DSEE.6.3.Solaris-Sparc-full.tar.gz
    tar xvf DSEE.6.3.Solaris-Sparc-full.tar

    For some reason, executing gunzip and tar with one command did not work on this compressed file.
  4. Make a directory named /opt/dsee.
  5. Install the Directory Server EE software into the /opt/ds directory.
    /ds/DSEE_ZIP_Distribution/dsee_deploy install -i /opt/dsee
  6. Press Enter until you reach the end of the license agreement.
  7. Type Yes when asked Do you accept the license terms? and press Enter to execute.
  8. Make a directory in which to store Directory Server EE instances.
    mkdir /opt/dsee/instances
  9. Change to the directory that contains the dsadm command-line interface.
    cd /opt/dsee/ds6/bin
  10. Create a new instance of Directory Server.
    ./dsadm create -p 389 -P 636 /opt/dsee/instances/ example
    You will be prompted to enter a password for cn=Directory Manager.
  11. Start the example instance.
    ./dsadm start /opt/dsee/instances/example
  12. Create the dc=example,dc=com suffix.
    ./dsconf create-suffix dc=example,dc=com
  13. Type Y to accept the server certificate.
  14. Enter the Directory Manager password.
    In the next steps, you will load the OpenSSO schema and add the Directory Server instance as a user data store with the OpenSSO console.

Because my installation initially used the embedded data store as a user store I was not able to select this Directory Server instance during configuration so I had to follow the instructions, Loading the OpenSSO Schema into Sun Java System Directory Server.

Finally, add the data store to a realm. I created a sub realm to the /Top Level Realm and added the data store to the sub realm.
  1. Login to the OpenSSO console as the administrator.
  2. Click the Access Control tab.
  3. Click New under Realms, enter the appropriate values and click OK to create a sub realm.
  4. Click the name of the new sub realm.
  5. Click the Data Stores tab.
  6. Remove the embedded data store, if applicable.
  7. Click New under Data Stores.
  8. Enter a name, select Sun DS with OpenSSO Schema, and click Next.
  9. Enter the appropriate server information and click OK.

At this point, I was able to create users using the OpenSSO console and the instance of Directory Server. I did have a some issues though viewing users I had imported from an LDIF file. Trainer extraordinaire David Goldsmith gave me these tips which worked.
  • Use the fully qualified host name as a value for LDAP Server when configuring the data store.
  • Set the Persistent Search Scope attribute to SCOPE_SUB as it is the default when you connect to an external LDAP directory during configuration.
  • Remove ou and people for the LDAP people container naming value and attribute. David wrote "I have no idea of why I had to blank out the 2 people container naming fields. I tried it because I used to have to do it in 7.0/7.1 but I have not had to do it in 8.0." The interesting thing about this tip is the values for those attributes are back. Maybe during restart, the attributes were repopulated?
So in honor of David and his bicycling ways, here is Queen with Bicycle Race, complete with footage from the bicycle race that was filmed especially for this video...back in the day. Those who were around...back in the day...might remember this footage. To you others, some quick elements are NSFW.

Thursday Apr 16, 2009

OpenSSO Express Build 7 is Released

So we did! Here are the link stats:

Download Link

Download Page on OpenSSO

Documentation on the new OpenSSO doc wiki.

Video of Englebert Humperdinck whose version of the standard Release Me helped to title the blog entry.

Tuesday Mar 31, 2009

Get Off My Case if You Can't Export OpenSSO Configuration Data

I wanted to export the configuration data on my install of OpenSSO so I went back to the directory that was created after I expanded opensso.zip to setup the ssoadm command line utility. Here are the steps I followed.
  1. Set JAVA_HOME and PATH variables to point to the correct version of Java; in this case, version 1.5.
    # JAVA_HOME=/usr/java/jdk1.5.0_14
    # export JAVA_HOME
    # PATH=$JAVA_HOME/bin:$PATH;
    # export PATH
  2. Create a directory into which you will expand the ssoAdminTools.zip.
    # mkdir /ssoadmtool
  3. Unzip ssoAdminTools.zip into the top-level directory created.
    # cd /opensso/tools
    # unzip ssoAdminTools.zip -d /ssoadmtool
    # cd /ssoadmtool
    # ls -la
    total 320
    drwxr-xr-x   6 root     root          10 Mar 31 10:42 .
    drwxr-xr-x  42 root     root          47 Mar 31 08:16 ..
    -rw-r--r--   1 root     root        4796 Mar 18 01:31 README.setup
    drwxr-xr-x   2 root     root          25 Mar 18 03:55 lib
    -rw-r--r--   1 root     root       17003 Mar 18 01:31 license.txt
    drwxr-xr-x   3 root     root           3 Mar 31 10:42 opensso
    drwxr-xr-x   2 root     root        1161 Mar 18 03:55 resources
    -rwxr-xr-x   1 root     root        2638 Mar 18 01:31 setup
    -rw-r--r--   1 root     root        3182 Mar 18 01:31 setup.bat
    drwxr-xr-x   4 root     root           4 Mar 18 01:31 template
  4. Run setup from the top-level ssoadmtool directory.
    # ./setup
    
    Path to config files of OpenSSO server (example: /opensso):/opensso
    Debug Directory:/opensso/debug
    Log Directory:/opensso/log
    The scripts are properly setup under directory: /ssoAdmin/opensso
    Debug directory is /opensso/debug.
    Log directory is /opensso/log.
    The version of this tools.zip is: (2009-March-18 01:14)
    The version of your server instance is: (2009-March-18 01:14)
  5. Run ssoadm using the export-svc-cfg option.

    ./ssoadm export-svc-cfg -e secretenckey -o /var/tmp/config.xml -u amadmin -f /tmp/password

    • e defines the key that will be used to encrypt any sensitive information in the configuration data store.
    • o defines the name and location of the XML file to which the configuration data will be written.
    • u defines the OpenSSO administrator; by default, amadmin.
    • f defines the name and location of the file that contains the OpenSSO administrator's password.

    config.xml is created in /var/tmp and contains the configuration data stored in the OpenSSO embedded configuration data store.
Now I'm exporting (-o you) the loveliness that is the Comateens singing Get Off My Case in the old train station in Hoboken, New Jersey. They are a great band singing in a great city in an OK state. And I would know - I lived in Hoboken for three years.

Monday Mar 09, 2009

Pop, OpenSSO Account Lock(out) and Drop

The OpenSSO Authentication Service provides a feature where a user will be locked out from authenticating after a defined number of failures. (More information is in the Sun OpenSSO Enterprise 8.0 Administration Guide.) When account lockout is enabled an attribute in the user data store is used to hold information regarding the authentication attempts. This information includes:
  • invalid attempts count
  • last failed time
  • lockout time
  • lockout duration
Many businesses have user data stores already configured for their overall deployment. If this is the case, the administrator might not want to (or need to) load the OpenSSO schema. The following procedure can be used to configure the account lockout feature to write this information to an attribute not defined by the OpenSSO schema.
  1. Login to the OpenSSO console as the administrator; be default, amadmin.
  2. Click the Realm tab.
  3. Under the Authentication tab, click Advanced Properties.
  4. Select Login Failure Lockout Mode to enable account lockout.
  5. On the same page, configure Invalid Attempts Data Attribute Name.

    Invalid Attempts Data Attribute Name is used if the OpenSSO schema is not loaded. Set the value of this property to the attribute name of your choice and OpenSSO will store the data as the value of this attribute. Note that the attribute you specify needs to also be defined in the LDAP User Attributes property of the data store configuration if the data store type is either Active Directory, Generic LDAPv3 or Sun DS with OpenSSO schema.

    NOTE: Store Invalid Attempts in Data Store is selected by default and enables the storage of the data as the value of the sunAMAuthInvalidAttemptsData attribute in the user data store. In order to store data in this attribute, the OpenSSO schema has to be loaded.

Now for those who can lock it, pop and drop it with some old skool funk, Peace Pipe by B.T. Express.

Wednesday Mar 04, 2009

Free OpenSSO Enterprise Training in San Francisco, CA

The week of April 6, Sun Learning Services is holding a five day training course for newbies to OpenSSo Enterprise 8.0. See the announcement posted on the OpenSSO web site.

And since the five day course is free, how about Queen and their song I Want to Break Free - a shocking video in America when it was first televised. Can this country be anymore provincial? (No answer necessary.)

Wednesday Feb 25, 2009

A Ticket to Localizing the OpenSSO Login Page

The mysterious Gina C, my compatriot in OpenSSO technical writing, has added an article to the 8.0 documentation called Localizing the Sun OpenSSO Enterprise 8.0 Login Page. It documents how to customize an OpenSSO Enterprise login page to contain localized text. Check it out.

And, since I know Gina C is a big Beatles fan, here's some live footage of the Beatles singing Ticket to Ride. If you listen closely you can hear Gina screaming.

Book title updated: 3/10/09)

Monday Feb 09, 2009

Deployment Example 2: SAE Expanded, Not Reduced

Some additional procedures have been made to the Secure Attribute Exchange (aka Virtual Federation) section of Deployment Example 2: SAML v2 Using Sun OpenSSO Enterprise 8.0. The section has been reorganized and changes made to 13.2 and 13.3, the identity provider and service provider configuration sections. You can see the new HTML version here on docs.sun.com tomorrow but you can download the new PDF from OpenSSO now.

And since SuperPat scoffs at my description of The Enemy as being old-school punk (pulling out his Coventry cred, no less) I decided to embed some real punk I happen to see back in the day (pulling out my CBGB cred, no less) from the Dead Boys. Check out Sonic Reducer.

About

docteger

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today