DocTeger

OpenSSO Technical Information

And a Spoonful of Music

To Make the Medicine Go Down

The JSON Schema Behind the Entitlements Service

What better day than Friday the 13th to write about the JavaScript Object Notation (JSON) schema used by the Entitlements Service to write the privilege objects returned by Those Darlin'OpenSSO REST Policy Evaluation Interfaces. JSON is relatively easy to read and understand. According to Introducing JSON, it is easy for machines to parse and generate...and is completely language independent but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others. These properties make JSON an ideal data-interchange language. (Check out the link for more information.)

An Entitlements Service privilege object has the following attributes:

• description is a descriptive string.
• entitlement is made up of:
  
  • name (any arbitrary unique String)
  • application name
  • set of action values (String to boolean)
  • list of resource names
  • a list of exclusive resource names
• subjects can include one or more entitlement subjects; in that case, logical subjects such as OrSubject and AndSubject are used. Please refer to sub section, Sub ject JSON Representation for schema for the support sub jects.
• conditions can include one or more conditions; in that case, logical conditions such as OrCondition and AndCondition are used. Please refer to sub section, Condition JSON Representation for schema for the support conditions.
• attributes may include user and static attributes.

There's more information to come but, in the meantime, here's another Jason - the Friday the 13th kind - in He's Back - The Man Behind the Mask. I don't know what's scarier the video (filled somewhat with oozing Karo Syrup) or this 80s-induced track sung by Alice Cooper. Mwahahahahahahahaha!!!!

Posted at 08:40AM Nov 13, 2009 by Michael Teger in Sun  |  Comments[0]

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.

Posted at 06:21AM Nov 12, 2009 by Michael Teger in Sun  |  Comments[0]

True to Enable Resource Authentication for OpenSSO Policy Agents

The new resource authentication feature (as documented Resource Authentication Type in OpenSSO Express 8) can also be enabled for deployments that use OpenSSO policy agents - either Web Agents or J2EE Agents. To enable resource authentication, a URL in the agent profile must be modified by appending to it the resource=true query parameter. The attribute that contains this URL is dependent upon whether the policy agent is configured in Cross Domain SSO (CDSSO) or not.

The procedure requires appending the "resource=true" query parameter to the "OpenSSO Login URL" or "CDSSO Servlet URL" field as follows:

1. Log into the OpenSSO console as administrator.
2. Click the Access Control tab.
3. Click the name of the appropriate realm.
4. Click the Agents tab.
5. Click the appropriate agent tab (Web or J2EE).
6. Click the name of the agent profile to modify.
7. Choose the appropriate sub step based on whether the agent is configured in CDSSO mode or not.
   • For an agent running in CDSSO mode, click the SSO tab and append resource=true to the existing value of the CDSSO Servlet URL attribute. For example, http://opensso.sun.com:8080/opensso/cdcservlet?resource=true.
   • For an agent NOT running in CDSSO mode, click the OpenSSO Services tab and append resource=true to the existing value of the OpenSSO Login URL attribute. For example, http://opensso.sun.com:8080/opensso/UI/Login?resource=true.

As Spandau Ballet once sang so beautifully, it's True.

Posted at 01:52PM Nov 11, 2009 by Michael Teger in Sun  |  Comments[0]

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
• Evaluating a More Specific Decision 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 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!

Posted at 12:51PM Nov 10, 2009 by Michael Teger in Sun  |  Comments[1]

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.

Posted at 04:52PM Nov 05, 2009 by Michael Teger in Sun  |  Comments[0]

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

Posted at 01:30PM Nov 02, 2009 by Michael Teger in Sun  |  Comments[0]

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?

Posted at 09:03AM Oct 20, 2009 by Michael Teger in Sun  |  Comments[2]

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.

Posted at 11:44AM Oct 13, 2009 by Michael Teger in Sun  |  Comments[2]

A Happy Working Song for the Technical Writer

My manager forwarded to the team this article on CNNMoney.com that ranks the best jobs in America. I was surprised to read that Technical Writer was only ranked at number 28. From my (admittedly skewed) perspective it should top the list.

Technical writing is a challenging job that offers the opportunity to educate yourself and others while getting paid. Over the years I've worked at some amazing companies, and with some incredibly talented people. And I get to write! And I get to create diagrams and illustrations! I might not have the paparazzi on my tail but can Nicole Richie explain the difference between symmetric and asymmetric key encryption? I think not.

So if you're a teen (or a parent of a teen) who is trying to decide what to do with yourself as an adult, read up on technical writing. It's a way of making a living that makes me want to sing a daily Happy Working Song (as embodied by Amy Adams in Enchanted).

Posted at 11:12AM Oct 09, 2009 by Michael Teger in Personal  |  Comments[0]

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
• Token Validation
• Logout
• Authorization
• Logging
• Searching for Identity Types
• Display Identity Data
• Display Particular Identity Data
• Creating Identity Types
• Updating Identity Data
• Deleting an Identity Profile

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.

Posted at 02:47PM Oct 08, 2009 by Michael Teger in Sun  |  Comments[7]

Larry Ellison and Ed Zander Together Again for the First Time

Check out this interview of Larry Ellison (future CEO of Sun assets if all goes as planned with the EU) by Ed Zander (former President of Sun Microsystems). Some interesting tidbits on our future.

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

A 2001 Holiday Party with IMS

I found these pictures of a holiday party the future OpenSSO team had on December 17, 2001. I believe at the time we were called Identity Management Services (IMS). Some are long gone, some are still here, and even then Ajay was leading the games. No music in this entry - just memories.

Posted at 12:00AM Oct 02, 2009 by Michael Teger in Sun  |  Comments[0]

Don't Be Tardy: Configure Password Expiration with OpenSSO and Identity Manager

In a deployment architecture that includes OpenSSO Enterprise 8.0 and Identity Manager 8.1.0.5 (to be released sometime in October) it is possible to configure user password reset based on the password's expiration date, or a help desk administrator's action. In the former use case, when a password is close to expiration, the user data store (which must be an LDAP directory server) can send a warning to the user based on the time configured in the assigned password policy. Upon accessing a resource protected by OpenSSO, the user would be redirected to Identity Manager to change the password. The URL of the protected resource is saved as a value of the goto parameter and the user will be redirected to this location after changing the password.

For the latter use case, if the user allows the password to expire, a help desk administrator can initiate the reset of the expired password by flagging the account and adding a temporary password to the user's profile. The administrator will then communicate the temporary password to the user (by email, for example). Upon logging into OpenSSO with this temporary password, the user will be directed to Identity Manager where the password is reset and the flag is removed.

The procedures documented will enable these use cases. Note that they only support the LDAP authentication module. The following sections contain the configuration procedures.

• Configuring the LDAP Directory Server
• Configuring OpenSSO
• Testing the Configurations

Configuring the LDAP Directory Server

For this procedure to work it is assumed that a password policy has been configured and assigned to the test user's LDAP profile in the directory server. The password policy should have the following controls related to password expiration set:

• Set Password Expiration (LDAP attribute: passwordexp, passwordmaxage)
• Set Expiration Warning (LDAP attribute: passwordwarning)
• Warning Duration (LDAP attribute: passwordExpireWithoutWarning)

It should also have the following controls set to allow for administrator-driven password reset:

• Require Password Change at First Login and After Reset (LDAP attribute: passwordchange, passwordmustchange)
• Allow Users to Change Their Passwords (LDAP attribute: pwdallowuserchange)

The passwordPolicySubentry attribute in the test user's LDAP profile should also be defined with the DN of the password policy to denote that the password policy has been assigned. See the documentation for your specific directory server for instructions on how to do these configurations.

Configuring OpenSSO

Only the OpenSSO LDAP authentication module supports the password change controls enforced by most directory servers. The following sections contain OpenSSO configurations.

• To Enable LDAP Authentication
• To Define Identity Manager URLs as Not Enforced
• Creating ChangePasswod.jsp
• Modifying the LDAP Authentication Module XML Service File
• Modifying the OpenSSO Login Page

To Enable LDAP Authentication

1. Login to the OpenSSO console as administrator.
2. Click the Access Control tab.
3. Click the appropriate realm name.
4. Click the Authentication tab.
5. Click New in the Authentication Chaining section to create a new authentication chain.
6. Enter a name for the chain and click OK.
   For this example use idmauth.
7. On the new chain's Properties page, add the LDAP module as REQUIRED and click Save.
8. Click Back to Authentication.
9. Select the service just created as the value for Organization Authentication Configuration.
10. Click LDAP in the Module Instances section.
11. Customize the LDAP properties to reflect your directory - at minimum:
    • Primary LDAP Server
    • DN to Start User Search
    • DN for Root User Bind
    • Password for Root User Bind
    • Password for Root User Bind (confirm)
12. Save the changes.
13. Logout from the OpenSSO console.

Note: Following this configuration:

• Use /opensso/console to log in to the OpenSSO console (not /opensso/UI/Login) to ensure that the authentication module configured for the OpenSSO administrator is used and not the LDAP module just configured.
• Login to the Identity Manager console and expand the OpenSSO resource listing to view the OpenSSO objects. If you receive an error, you may need to reconfigure the OpenSSO adaptor to use a delegated administrator rather than amadmin to connect to OpenSSO. The Identity Manager adaptor for OpenSSO authenticates to OpenSSO using the authentication configuration for the realm which is now different from the configuration for the OpenSSO console. Thus, amadmin will no longer work. See Delegating Administrator Privileges for information on delegating administrative privileges to a group.

To Define Identity Manager URLs as Not Enforced

1. Login to the OpenSSO console as administrator.
2. Click the Access Control tab.
3. Click the appropriate realm name and navigate to the Agents profile for the policy agent that protects Identity Manager.
4. Under the agent profile, click the Application tab.
5. Add the following URIs to the Not Enforced URIs property.
   
   • /idm/authutil/
   • /idm/authutil/*
   • /idm/authutil/*?*
6. Click Save.
7. Logout of OpenSSO.

To Create ChangePassword.jsp

This procedure documents how to create ChangePassword.jsp, a custom JSP for redirecting a user to Identity Manager for password change events. (By default, the user would be directed to the OpenSSO password change page.) ChangePassword.jsp will forward the following information to Identity Manager:

• The original URL requested by the user and defined as the value of the goto parameter.
• The user identifier defined as the value of the accountId parameter

1. Change to the opensso/integrations/idm/jsps/ directory in the decompressed opensso.zip to access the sample ChangePassword.jsp.
2. Modify the Identity Manager URL in the JSP based on your deployment.
3. Copy ChangePassword.jsp to /web-container-deploy-base/opensso/config/auth/default/ and to /web-container-deploy-base/opensso/config/auth/default_en/.
4. Remove the web containers temporary, compiled JSP to ensure that the changes made are picked up.
   For example, if using Glassfish, the temporary, compiled classes can be found under glassfish-home/domains/your-domain/generated/.
5. Restart the OpenSSO web container after making the changes.

Modifying the LDAP Authentication Module XML Service File

This procedure documents how to modify LDAP.xml to use ChangePassword.jsp. There are two options to consider when deciding how to modify LDAP.xml. You can manually change the deployed LDAP.xml file, or you can use the sample LDAP.xml included with the opensso.zip download. They are mutually exclusive so choose only one of these procedures.

• To Manually Modify a Deployed LDAP.xml
• To Use the Sample LDAP.xml

To Manually Modify a Deployed LDAP.xml

1. Change to the /web-container-deploy-base/opensso/config/auth/default/ directory to access the deployed LDAP.xml page.
2. Open LDAP.xml in an editor and add the section of code displayed in yellow in admin_pwd_reset_ldap.html on the OpenSSO web site.
3. Change to the /web-container-deploy-base/opensso/config/auth/default_en/ directory to access the second copy of LDAP.xml and make the same change.
4. Remove the web containers temporary, compiled JSP to ensure that the changes made are picked up.
   For example, if using Glassfish, the temporary, compiled classes can be found under glassfish-home/domains/your-domain/generated/.
5. Restart the OpenSSO web container after making the changes.

To Use the Sample LDAP.xml

1. Change to the opensso/integrations/idm/xml/ directory in the decompressed opensso.zip to access the sample LDAP.xml.
2. Replace your deployed /web-container-deploy-base/opensso/config/auth/default/LDAP.xml with the sample LDAP.xml in two directories:
   • /web-container-deploy-base/opensso/config/auth/default/
   • /web-container-deploy-base/opensso/config/auth/default_en/
   If you replace your existing LDAP.xml with the sample LDAP.xml you will lose any custom changes made to the existing LDAP.xml.
3. Remove the web containers temporary, compiled JSP to ensure that the changes made are picked up.
   For example, if using Glassfish, the temporary, compiled classes can be found under glassfish-home/domains/your-domain/generated/.
4. Restart the OpenSSO web container after making the changes.

Optionally, you can run diff between both files and make the necessary changes manually.

Modifying the OpenSSO Login Page

This procedure documents how to modify Login.jsp with the necessary code to save the URL value of the goto parameter in the HTTP request. This saved URL is required by the ChangePassword.jsp. The saved URL (which is the original location desired by the user) will be passed to Identity Manager and used to redirect the user after unlocking has been completed.

There are two options to consider when deciding how to embed code into the OpenSSO Login.jsp. You can manually change the deployed Login.jsp file, or you can use the sample Login.jsp included with the opensso.zip download. They are mutually exclusive so choose only one of these procedures.

• To Manually Modify a Deployed Login.jsp
• To Use the Sample Login.jsp

To Manually Modify a Deployed Login.jsp

1. Change to the /web-container-deploy-base/opensso/config/auth/default/ directory to access the deployed Login.jsp page.
2. Open Login.jsp in an editor and add the two (2) sections of code displayed in yellow in admin_pwd_reset_login.html on the OpenSSO web site.
3. Remove the web containers temporary, compiled JSP to ensure that the changes made are picked up.
   For example, if using Glassfish, the temporary, compiled classes can be found under glassfish-home/domains/your-domain/generated/.
4. Restart the OpenSSO web container after making the changes.

To Use the Sample Login.jsp

1. Change to the opensso/integrations/idm/jsps/ directory in the decompressed opensso.zip to access the sample Login.jsp.
2. Change the Identity Manager URL embedded in the sample Login.jsp to reflect the Identity Manager system URL of your architecture.
   You can search for the string /idm to locate the URLs.
3. Replace your deployed /web-container-deploy-base/opensso/config/auth/default/Login.jsp with the sample Login.jsp.
   If you replace your existing Login.jsp with the sample Login.jsp the following will occur.
   • You will lose any custom changes made to the existing Login.jsp.
   • You will inherit changes that might have been previously made to the sample Login.jsp to incorporate requirements for other use cases related to the OpenSSO integration with Identity Manager.
4. Remove the web containers temporary, compiled JSP to ensure that the changes made are picked up.
   For example, if using Glassfish, the temporary, compiled classes can be found under glassfish-home/domains/your-domain/generated/.
5. Restart the OpenSSO web container after making the changes.

Optionally, you can run diff between both files and make the necessary changes manually.

Testing The Configurations

Perform the tests in the order in which they are described to understand and verify the behavior for each stage of this use case.

A. Testing Password Warning Expiration

Perform the following actions after the time the password expiration warning, as defined in the password policy, would take effect.

1. Access a URL protected by OpenSSO.
   The OpenSSO login page is displayed.
2. Enter the test user name and password.
   You will be redirected to Identity Manager to change your password. Note the following about the Identity Manager URL:
   • The URL is the one configured in ChangePassword.jsp.
   • The user will be forwarded to the value of the goto parameter after the password has been successfully changed.
   • The value of the accountId parameter determines the account for which the password needs to be changed. Identity Manager will make the changes to the password on both Identity Manager and OpenSSO.

B. Testing Password Expiration

Perform the following actions after the time the password should have expired, as defined in the password policy.

1. Access a URL protected by OpenSSO.
   The OpenSSO login page is displayed.
2. Enter the test user name and password.
   An error page is displayed informing the test user that the password has expired. The user will be instructed to have the administrator reset the password.

C. Testing Administrator Password Reset

1. Refer to your directory server documentation to enable audit and logging.
   Monitor the directory server audit log as you finish the test.
2. Login as the directory administrator and change the password for a test user.
   This simulates the password reset by a help desk administrator.
3. Verify that the user's userPassword attribute was modified and the pwdreset was set to TRUE using the audit log.
   The pwdreset attribute will force the user to change the password at the next login. The audit log might resemble this sample.

   time: 20090713074720
   dn: uid=idmuser1,dc=sun,dc=com
   changetype: modify
   replace: userPassword
   userPassword: {SSHA}4Bgy/HF9SGN9nnS4Ii6/KJj9ktFdAxQUIDvwVQ==
   -
   replace: modifiersname
   modifiersname: cn=admin,cn=administrators,cn=dscc
   -
   replace: modifytimestamp
   modifytimestamp: 20090713144720Z
   -
   replace: passwordexpirationtime
   passwordexpirationtime: 19700101000000Z
   -
   replace: pwdreset
   pwdreset: TRUE
   

4. Access the Identity Manager user URL.
   You will be redirected to OpenSSO for login.
5. Enter the test user name and password.
   You will be redirected to Identity Manager to change your password. Note the following about the Identity Manager URL:
   • The URL is the one configured in ChangePassword.jsp.
   • The user will be forwarded to the value of the goto parameter after the password has been successfully changed.
   • The value of the accountId parameter determines the account for which the password needs to be changed. Identity Manager will make the changes to the password on both Identity Manager and OpenSSO.

For those fans of The Real Housewives of Atlanta, here's a fan-made video of Kim Zolciak's (Don't Be) Tardy for the Party. (I added the parentheticals to make it seem official.) Kandi Burress produced a dance floor smash for the woman who can not sing! Who knew?

Posted at 08:25AM Sep 29, 2009 by Michael Teger in Sun  |  Comments[0]

Configuring Self Unlock After Account Lockout Using OpenSSO and Identity Manager is Fun

User account lockout in OpenSSO can happen in either of the following ways:

• Memory account lockout occurs when the user has exceeded the allowed number of failed attempts to log in as configured in the password policy. The user may remain locked out for a set period of time and can only reset the password after that period has passed. The locked state of the user account is maintained in memory and no information is written to the user's LDAP profile.
• Physical account lockout occurs when the status of a specified LDAP attribute in the user’s profile is explicitly changed to Inactive, either by an administrator or as a result of some automated processes. (The specified LDAP attribute is defined as the value of the Lockout Attribute Name attribute in the Core authentication module.) By default it is inetuserstatus.

When a user's account is locked, it is possible to allow the user to unlock the account without intervention from an administrator. The procedures documented will enable this for a deployment with OpenSSO Enterprise 8.0 and Identity Manager 8.1.0.5 (to be released sometime in October). Note that memory account lockout in OpenSSO must be disabled using the OpenSSO console as the account lockout controls in the user data store will be used. Using this feature in a deployment with OpenSSO and Identity Manager only supports the LDAP authentication module. The following sections contain the configuration procedures.

• Configuring the LDAP Directory Server
• Configuring OpenSSO
• Testing the Configurations

Configuring the LDAP Directory Server

For this procedure to work it is assumed that a password policy has been configured and assigned to the test user's LDAP profile in the directory server. The password policy should have the following controls set:

• Enable Account Lockout (LDAP attribute: passwordLockout)
• Failures Before Lockout (LDAP attribute: passwordMaxFailure)
• Failure Count Reset (LDAP attribute: passwordResetFailureCount)
• Set Limit on Lockout Duration (LDAP attribute: passwordUnlock)
• Lockout Duration (LDAP attribute: passwordLockoutDuration)

The passwordPolicySubentry attribute in the test user's LDAP profile should also be defined with the DN of the password policy to denote that the password policy has been assigned. See the documentation for your specific directory for instructions on how to do these configurations.

Configuring OpenSSO

The OpenSSO LDAP authentication module supports the account lockout controls enforced by most directory servers. The following sections contain OpenSSO configurations.

• To Enable LDAP Authentication
• To Define Identity Manager URLs as Not Enforced
• Modifying the OpenSSO Login Page
• Modifying the OpenSSO Account Lockout Message Page

To Enable LDAP Authentication

1. Login to the OpenSSO console as administrator.
2. Click the Access Control tab.
3. Click the appropriate realm name.
4. Click the Authentication tab.
5. Click New in the Authentication Chaining section to create a new authentication chain.
6. Enter a name for the chain and click OK.
   For this example use idmauth.
7. On the new chain's Properties page, add the LDAP module as REQUIRED and click Save.
8. Click Back to Authentication.
9. Select the service just created as the value for Organization Authentication Configuration.
10. Save the changes.
11. Logout from the OpenSSO console.

Note: Following this configuration, use /opensso/console to log in to the OpenSSO console (not /opensso/UI/Login) to ensure that the authentication module configured for the OpenSSO administrator is used and not the LDAP module just configured.

To Define Identity Manager URLs as Not Enforced

1. Login to the OpenSSO console as administrator.
2. Click the Access Control tab.
3. Click the appropriate realm name and navigate to the Agents profile for the policy agent that protects Identity Manager.
4. Under the agent profile, click the Application tab.
5. Add the following URIs to the Not Enforced URIs property.
   
   • /idm/authutil/
   • /idm/authutil/*
   • /idm/authutil/*?*
6. Click Save.
7. Logout of OpenSSO.

Modifying the OpenSSO Login Page

This procedure documents how to modify Login.jsp with the necessary code for this use case. The code will save the value of the goto parameter in the HTTP request. This saved URL is required by the user_inactive.jsp created in the next procedure. The saved URL (which is the original location desired by the user) will be passed to Identity Manager and used to redirect the user after unlocking has been completed.

There are two options to consider when deciding how to embed code into the OpenSSO Login.jsp. You can manually change the deployed Login.jsp file, or you can use the sample Login.jsp included with the opensso.zip download. They are mutually-exclusive so choose only one of these procedures.

• To Manually Modify a Deployed Login.jsp
• To Use the Sample Login.jsp

To Manually Modify a Deployed Login.jsp

1. Change to the /web-container-deploy-base/opensso/config/auth/default/ directory to access the deployed Login.jsp page.
2. Open Login.jsp in an editor and add the two (2) sections of code displayed in yellow in account_unlock_login.html on the OpenSSO web site.
3. Remove the web containers temporary, compiled JSP to ensure that the changes made are picked up.
   For example, if using Glassfish, the temporary, compiled classes can be found under glassfish-home/domains/your-domain/generated/.
4. Restart the OpenSSO web container after making the changes.

To Use the Sample Login.jsp

1. Change to the opensso/integrations/idm/jsps/ directory in the decompressed opensso.zip to access the sample Login.jsp.
2. Change the Identity Manager URL embedded in the sample Login.jsp to reflect the Identity Manager system URL of your architecture.
   You can search for the string /idm to locate the URLs.
3. Replace your deployed /web-container-deploy-base/opensso/config/auth/default/Login.jsp with the sample Login.jsp.
   If you replace your existing Login.jsp with the sample Login.jsp the following will occur.
   • You will lose any custom changes made to the existing Login.jsp.
   • You will inherit changes that might have been previously made to the sample Login.jsp to incorporate requirements for other use cases related to the OpenSSO integration with Identity Manager.
4. Remove the web containers temporary, compiled JSP to ensure that the changes made are picked up.
   For example, if using Glassfish, the temporary, compiled classes can be found under glassfish-home/domains/your-domain/generated/.
5. Restart the OpenSSO web container after making the changes.

Optionally, you can run diff between both files and make the necessary changes manually.

Modifying the OpenSSO Account Lockout Message Page

This procedure documents how to modify user_inactive.jsp, the JSP that notifies the user that the account is locked. You will modify the page to include a redirect to an Identity Manager page that will enable the user to unlock the account. user_inactive.jsp will forward the following information to Identity Manager:

• The original URL requested by the user and defined as the value of the goto parameter.
• The user identifier defined as the value of the accountId parameter

There are two options to consider when deciding how to embed code into the OpenSSO user_inactive.jsp. You can manually change the deployed user_inactive.jsp file, or you can use the sample user_inactive.jsp included with the opensso.zip download. They are mutually exclusive so choose only one of these procedures.

• To Manually Modify the Account Lockout Message Page
• To Use the Account Lockout Message Page

To Manually Modify the Account Lockout Message Page

1. Change to the /web-container-deploy-base/opensso/config/auth/default/ directory to access the deployed user_inactive.jsp page.
2. Open user_inactive.jsp in an editor and add the two (2) sections of code displayed in yellow in account_unlock_inactive.html on the OpenSSO web site.
   Embedded in the JSP, you will see the URL to the Identity Manager page that allows the account unlock. You should modify this URL as per your deployment.
3. Remove the web containers temporary, compiled JSP to ensure that the changes made are picked up.
   For example, if using Glassfish, the temporary, compiled classes can be found under glassfish-home/domains/your-domain/generated/.
4. Restart the OpenSSO web container after making the changes.

Note: The Identity Manager URL used in the sample refers to anonResetPassword.jsp. You might, however, direct the user to questionLogin.jsp, the forgotten password page because if a user has accidentally locked an account it may be because of a forgotten password.

To Use the Sample Account Lockout Message Page

1. Change to the opensso/integrations/idm/jsps/ directory in the decompressed opensso.zip to access the sample user_inactive.jsp.
2. Change the Identity Manager URL embedded in the sample Login.jsp to reflect the Identity Manager system URL of your architecture.
   You can search for the string /idm to locate the URLs.
3. Replace your deployed /web-container-deploy-base/opensso/config/auth/default/user_inactive.jsp with the sample user_inactive.jsp.
   If you replace your existing user_inactive.jsp with the sample user_inactive.jsp the following will occur.
   • You will lose any custom changes made to the existing Login.jsp.
   • You will inherit changes that might have been previously made to the sample Login.jsp to incorporate requirements for other use cases related to the OpenSSO integration with Identity Manager.
4. Remove the web containers temporary, compiled JSP to ensure that the changes made are picked up.
   For example, if using Glassfish, the temporary, compiled classes can be found under glassfish-home/domains/your-domain/generated/.
5. Restart the OpenSSO web container after making the changes.

Optionally, you can run diff between both files and make the necessary changes manually.

Testing The Configurations

The following procedures document testing these configurations for memory account lockout and physical account lockout.

• To Test Memory Account Lockout
• To Test Physical Account Lockout

To Test Memory Account Lockout

1. Configure the password policy and assign the policy to the test user.
   This is done using the user data store.
2. Access a resource protected by OpenSSO to get redirected to the login page.
3. Login to OpenSSO using an incorrect password.
   Do this consecutively until the account gets locked and the error page is displayed. This will be dependent on the number of attempts configured in the password policy.
4. Click the hyperlink on the page.
   You will be redirected to an Identity Manager page on which you will be required to change your password. Note that the URL is the one configured in the user_inactive.jsp.
5. Change your password.
   Identity Manager determines the account from the accountID parameter and will change the password on both OpenSSO and Identity Manager. After a successful modification, the user will be redirected to the original URL defined in the goto parameter.

To Test Physical Account Lockout

1. Set the value of the inetuserstatus attribute in the test user's profile in the user data store to Inactive.
2. Access a resource protected by OpenSSO to get redirected to the login page.
3. Login to OpenSSO.
   An error page will be displayed informing you that the account has been locked.
4. Click the hyperlink on the page.
   You will be redirected to an Identity Manager page on which you will be required to change your password. Note that the URL is the one configured in the user_inactive.jsp.
5. Change your password.
   Identity Manager determines the account from the accountID parameter and will change the password on both OpenSSO and Identity Manager. After a successful modification, the user will be redirected to the original URL defined in the goto parameter.

And now here are some girls doing it for themselfes: Cyndi Lauper, Ann Wilson, Nancy Wilson, Wynona Judd, Amy Grant and Destiny's Child (Beyonce, Kelly Rowland and Michelle Williams) performing a live version of Hey Now (Girls Just Wanna Have Fun).

Posted at 12:00AM Sep 28, 2009 by Michael Teger in Sun  |  Comments[5]

A Look at Enabling Automatic OpenSSO Provisioning After Identity Manager Self-registration

Here's a look at the procedures to enable auto provisioning of OpenSSO Enterprise 8.0 with a user account created on-the-fly by a user accessing Identity Manager 8.1.0.5 (to be released sometime in October) for the first time. (They are being integrated into the OpenSSO Integration Guide as I type.) The configurations will allow an end user to create a personal account on Identity Manager and, following creation, this account data will be provisioned to OpenSSO automatically. The user account created would be the most basic account with the minimum privileges available.

In the Identity Manager WAR, /idm is the base context of the deployment. The architecture of this use case assumes there is a policy agent protecting Identity Manager.

• Configuring OpenSSO
• Configuring Identity Manager
• Testing the Configurations

Configuring OpenSSO

To configure OpenSSO, you will define Identity Manager URIs as not enforced for the policy agent. You will also need to modify the OpenSSO login page so that it will display a Register User button.

To Define Identity Manager URLs as Not Enforced

1. Login to the OpenSSO console as administrator.
2. Click the Access Control tab.
3. Click the appropriate realm name and navigate to the Agents profile for the policy agent that protects Identity Manager.
4. Under the agent profile, click the Application tab.
5. Add the following URIs to the Not Enforced URIs property.
   
   • /idm/authutil/
   • /idm/authutil/*
   • /idm/authutil/*?*
6. Click Save.
7. Logout of OpenSSO.

Modifying the OpenSSO Login Page

There are two options to consider when deciding how to display a Register User button on the OpenSSO login page. You can manually change the deployed Login.jsp file, or you can use the sample Login.jsp included with the opensso.zip download. They are mutually-exclusive so choose only one of these procedures.

• To Manually Modify a Deployed Login.jsp
• To Use the Sample Login.jsp

To Manually Modify a Deployed Login.jsp

1. Change to the /web-container-deploy-base/opensso/config/auth/default/ directory to access the deployed Login.jsp page.
2. Open Login.jsp in an editor and add the five (5) sections of code displayed in yellow in self_registration_login.html on the OpenSSO web site.
3. Remove the web containers temporary, compiled JSP to ensure that the changes made are picked up.
   For example, if using Glassfish, the temporary, compiled classes can be found under glassfish-home/domains/your-domain/generated/.
4. Restart the OpenSSO web container after making the changes.

To Use the Sample Login.jsp

1. Change to the opensso/integrations/idm/jsps/ directory in the decompressed opensso.zip to access the sample Login.jsp.
2. Change the Identity Manager URL embedded in the sample Login.jsp to reflect the Identity Manager system URL of your architecture.
   You can search for the string /idm to locate the URLs.
3. Replace your deployed /web-container-deploy-base/opensso/config/auth/default/Login.jsp with the sample Login.jsp.
   If you replace your existing Login.jsp with the sample Login.jsp the following will occur.
   • You will lose any custom changes made to the existing Login.jsp.
   • You will inherit changes that might have been previously made to the sample Login.jsp to incorporate requirements for other use cases related to the OpenSSO integration with Identity Manager.
4. Remove the web containers temporary, compiled JSP to ensure that the changes made are picked up.
   For example, if using Glassfish, the temporary, compiled classes can be found under glassfish-home/domains/your-domain/generated/.
5. Restart the OpenSSO web container after making the changes.

Optionally, you can run diff between both files and make the necessary changes manually.

Configuring Identity Manager

To configure Identity Manager, you will change the registration work flow. There are two options to consider when deciding how to change the registration work flow. You can use the Identity Manager plug-in for NetBeans IDE or, use the Identity Manager Debug Pages. They are mutually-exclusive so choose only one of these procedures.

• To Change the Registration Work Flow Using Netbeans IDE
• To Use the Identity Manager Debug Pages

To Change the Registration Work Flow Using Netbeans IDE

This procedure assumes that you have downloaded and installed NetBeans IDE and downloaded and installed the Identity Manager Plug-in for NetBeans.

1. Create (or open) an Identity Manager Project in NetBeans.
   There are two types of projects: integrated and remote. This procedure applies in either case. Use the online help available in NetBeans to create the Identity Manager project if necessary. The Identity Manager IDE website also has some pointers.
2. From the NetBeans Project Window, right-click on the Custom Identity Manager Objects Node and select IDM > Open Object.
3. In the Open Object dialog box, enter the object name End User Anonymous Enrollment and select OK.
4. Right-click on the file in the Project Window and select IDM > Clone Object(s) to clone the object for safe keeping.
5. Name the new object End User Anonymous Enrollment Orig.
6. Click on the tab in the Editor window containing the file End User Anonymous Enrollment work flow.
   This will put the file in focus.
7. Expand the tree in the Navigator Window to locate the Activity Assimilate User View.
8. Add the OpenSSO resource to the map of options for the "assimilate" invocation.
   Refer to self_registration_idm_anon_enroll.html on OpenSSO for the changes to be made to the object. The name of the OpenSSO resource (OpenSSO in self_registration_idm_anon_enroll.html) is the name assigned when the resource was created. To verify the name, navigate to the "Resources | List Resources" tab in the Identity Manager administration console and expand the "Sun Access Manager Realm" branch.
9. Save the changes.
10. Right-click on the file and select IDM > Upload Object(s) to upload the file.

To Use the Identity Manager Debug Pages

1. Login to the Identity Manager console as administrator.
2. Go to the debug URL at protocol://IDM-host-machine:port/idm/debug.
3. Select the object "Task Definition" in the list next to the "List Objects" button.
4. Click on the "List Objects" button.
5. Search for the object "End User Anonymous Enrollment" and click on its "edit" hyperlink.
   You might first export the existing definition and save it.
6. Add the OpenSSO resource to the Activity "Assimilate User View".
   Refer to self_registration_idm_anon_enroll.html on OpenSSO for the changes to be made to the object. The name of the OpenSSO resource (OpenSSO in self_registration_idm_anon_enroll.html) is the name assigned when the resource was created. To verify the name, navigate to the "Resources | List Resources" tab in the Identity Manager administration console and expand the "Sun Access Manager Realm" branch.
7. Logout of the console.

Testing The Configurations

Perform the tests in the order in which they are described to understand and verify the behavior for each stage of this use case.

A. User Self-Registration

1. Go to the OpenSSO login URL at protocol://OSSO-host-machine:port/opensso/UI/Login.
2. Click the "Register User" button to register a test user.
3. Go through the registration process and click the "Register" button.
   A message is displayed signifying that the registration request is being processed.

B. Approval Of New User Account

1. Login to the Identity Manager console as an administrator.
   The "Create User" pending task is displayed as "Create User ".
2. Navigate to the "Work Items | Approvals" tab.
3. Select the provisioning task for the new user-id and click the "Approve" button.
4. Confirm the approval.
5. Logout of the Identity Manager console.

C. Verify Provisioning Of New User Account

1. Login to the OpenSSO console as administrator.
2. Navigate to the "Access Control | realm | Subjects" tab.
   The approved user is displayed indicating that the profile was successfully registered and provisioned.

D. Verify Activation Of New User Account

1. Go to the OpenSSO login URL at protocol://OSSO-host-machine:port/opensso/UI/Login and login as the new user.
   A successful login indicates that the new user is active.
2. Logout of OpenSSO.

Now on to another look, Just One Look from Linda Ronstadt.

Posted at 09:06AM Sep 23, 2009 by Michael Teger in Sun  |  Comments[0]