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.
Posted at 12:00AM Nov 17, 2009 by Michael Teger in Sun | Comments[0]
Configuring Identity Manager Password Reset with OpenSSO NOW
The following information concerns extending the end user password reset or forgot password feature to include Identity Manager 8.1.0.5 to be released sometime in October. (I wrote this weeks ago but forgot to publish it.) In a deployment that has both products integrated, a user needs the option to change or reset a configured password. To allow for identification, challenge questions should be configured for each user account. Unless these questions are answered correctly, this behavior will not be allowed. The flow diagram below details the process. (Right click it to open it full size in a new tab or window.)

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 Forgot Password button.To Define Identity Manager URLs as Not Enforced
- Login to the OpenSSO console as administrator.
- Click the Access Control tab.
- Click the appropriate realm name and navigate to the Agents profile for the policy agent that protects Identity Manager.
- Under the agent profile, click the Application tab.
- Add the following URIs to the Not Enforced URIs property.
/idm/authutil//idm/authutil/*/idm/authutil/*?*
- Click Save.
- Logout of OpenSSO.
Modifying the OpenSSO Login Page
There are two options to consider when deciding how to display a Forgot Password button on the OpenSSO login page. You can manually change the deployedLogin.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
- Change to the
/web-container-deploy-base/opensso/config/auth/default/directory to access the deployedLogin.jsppage. - Open
Login.jspin an editor and add the five (5) sections of code displayed in yellow in forgot_pwd.html on the OpenSSO web site.
The URL in one section of this page that ends.../idm/authutil/questionLogin.jsp?accountId=links to the Identity Manager JSP that will be displayed if the user does not have challenge questions configured. Replace the beginning of this URL (http://am-v490-01.red.iplanet.com:6480/idm/authutil/questionLogin.jsp?accountId=in the file) with the specifics of your deployment. - 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 underglassfish-home/domains/your-domain/generated/. - Restart the OpenSSO web container after making the changes.
To Use the Sample Login.jsp
- Change to the
opensso/integrations/idm/jsps/directory in the decompressedopensso.zipdirectory to access the sampleLogin.jsp. - Change the Identity Manager URL embedded in the sample
Login.jspto reflect the Identity Manager system URL of your architecture.
You can search for the string/idmto locate the URLs. - Replace your deployed
/web-container-deploy-base/opensso/config/auth/default/Login.jspwith the sampleLogin.jsp.
If you replace your existingLogin.jspwith the sampleLogin.jspthe 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.jspto incorporate requirements for other use cases related to the OpenSSO integration with Identity Manager.
- You will lose any custom changes made to the existing
- 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 underglassfish-home/domains/your-domain/generated/. - Restart the OpenSSO web container after making the changes.
diff between both files and make the necessary changes manually.
Test The Configurations
- Access an Identity Manager URL.
You will be redirected to the OpenSSO login page. - Enter a username and click the "Forgot Password" button.
You will be redirected to the Identity ManagerquestionLogin.jsp. - Enter answers to the challenge questions and click the "Login" button.
You will be redirected to second page. - Enter your new password on this second page.
This is a temporary password you would've received from contacting the help desk. See the process flow diagram above. - Select the option to update all resource accounts.
Ensure that both the Identity Manager and OpenSSO resources are selected. - Select the option in the column "Forgot Old Password?" for the OpenSSO Resource.
- Click the "Change Password" button.
The password is now changed. Use the new password next time you log in.
Posted at 12:00AM Nov 16, 2009 by Michael Teger in Sun | Comments[0]
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:descriptionis a descriptive string.entitlementis 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
subjectscan include one or more entitlement subjects; in that case, logical subjects such asOrSubjectandAndSubjectare used. Please refer to sub section, Sub ject JSON Representation for schema for the support sub jects.conditionscan include one or more conditions; in that case, logical conditions such asOrConditionandAndConditionare used. Please refer to sub section, Condition JSON Representation for schema for the support conditions.attributesmay include user and static attributes.
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.
- Log into the OpenSSO console as administrator.
- Click the Access Control tab.
- Click the name of the appropriate realm.
- Click the Agents tab.
- Click the appropriate agent tab (Web or J2EE).
- Click the name of the agent profile to modify.
- 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=trueto 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=trueto the existing value of the OpenSSO Login URL attribute. For example,http://opensso.sun.com:8080/opensso/UI/Login?resource=true.
- For an agent running in CDSSO mode, click the SSO tab and append
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¶meter2=value2¶meterN=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
Thedecision 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.
realmdefines the realm in which the subject is defined. This is an optional parameter and the default value is/.subjectdefines the value of the Universal ID attribute in the requesting user's OpenSSO profile.actiondefines the action to be evaluated.resourcedefines the resource to be evaluated.applicationdefines the requested service. This is an optional parameter and the default value isiPlanetAMWebAgentService.envdefines an optional environment map. This map may contain information such as the date and time or the IP address of the client. Examples might beenv=requestIp%3D125.12.133.1orenv=requestTime%3D1248994000000.
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
Theentitlement 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.
realmdefines the realm in which the subject is defined. This is an optional parameter and the default value is/.subjectdefines the value of the Universal ID attribute in the requesting user's OpenSSO profile.resourcedefines the resource to be evaluated.applicationdefines the requested service. This is an optional parameter and the default value isiPlanetAMWebAgentService.envdefines an optional environment map. This map may contain information such as the date and time or the IP address of the client. Examples might beenv=requestIp%3D125.12.133.1orenv=requestTime%3D1248994000000.
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
Thedecisions 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.
realmdefines the realm in which the subject is defined. This is an optional parameter and the default value is/.subjectdefines the value of the Universal ID attribute in the requesting user's OpenSSO profile.resourcesdefines the set of resources to be evaluated. More than oneresourcesparameter may be added to the URL.applicationdefines the (application or application type). This is an optional parameter and the default value isiPlanetAMWebAgentService.envdefines an optional environment map. This map may contain information such as the date and time or the IP address of the client. Examples might beenv=requestIp%3D125.12.133.1orenv=requestTime%3D1248994000000.
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
Theentitlements 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.
realmdefines the realm in which the subject is defined. This is an optional parameter and the default value is/.subjectdefines the value of the Universal ID attribute in the requesting user's OpenSSO profile.resourcedefines the root of the set of resources to be evaluated.applicationdefines the requested service. This is an optional parameter and the default value isiPlanetAMWebAgentService.envdefines an optional environment map. This map may contain information such as the date and time or the IP address of the client. Examples might beenv=requestIp%3D125.12.133.1orenv=requestTime%3D1248994000000.
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.
- Log into the OpenSSO console as administrator.
- Click the Configuration tab.
- Click the Servers and Sites tab.
- Click the Server name in the Servers table.
- Click the Advanced tab.
- Click Add in the Advanced Properties table.
- Enter
ssoadm.disabledas the Property Name andtrueas the Property Value. - Click Save.
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.
- Log into the OpenSSO console as administrator.
- Click the Federation tab.
- Click the name of the entity provider for which you want switch off a particular SAMLv2 Service.
- Click the Services tab.
- Remove the appropriate endpoint.
- Click Save.
ssoadm command line interface.
- Use
ssoadm export-entityto export the extended metadata. - Modify the exported extended metadata.
- Use
ssoadm delete-entityto delete the original extended metadata. - Use
ssoadm import-entityto import the modified extended metadata.
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?
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.
- 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
getIdentitymethod incom.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 incom.sun.identity.idm.AMIdentity.
- 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
- 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). - 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
SSOTokenor 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.
- 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
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¶meter2=value2¶meterN=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
Theauthenticate 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
TheisTokenValid 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
Thelogout 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
Theauthorize 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
Thelog REST interface will log to the OpenSSO Logging Service. The URL needs to be populated with the following information.
appiddefines thetokenidof the user with the necessary permissions to write to the log; for exampleamadmin.subjectiddefines thetokenidof the user about whom the log record is being written.lognameis the module name of the OpenSSO component invoking the Logging Service; for example,amAuthentication.messageis the data being logged.
http://OpenSSO-host:OpenSSO-port/opensso/identity/log?appid=AQIC5wM2LY4Sfcz24GvZCdv6ie9dTJBa3Co7Rn2QUjKCDuM=@AAJTSQACMDE=#&subjectid=AQIC5wM2LY4SfcwTCcRKSDXEsiJXt71PDAUmN1bm/draPZI=@AAJTSQACMDE=#&logname=amAuthentication&message=test
Searching Identity Types
Thesearch REST interface will search the configured database for particular identities. The URL needs to be populated with the following information.
filterdefines a set of criteria that controls what is returned by the operation.attributes_namedefines one or more LDAP attributes for which to search.attribute_values_value-of-attributes_namedefines the value of the attribute (defined byattributes_name) that is being searched.admindefines thetokenidof the user with the necessary permissions to search; for exampleamadmin.
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
Theattributes 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
Theread 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
Thecreate 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_namedefines a easily-readable name for the identity.identity_attribute_namesdefines one or more LDAP attributes to be created for the identity.identity_attribute_values_value-of-identity_attribute_namesdefines the value of the attribute (defined byattributes_name) being created.identity_realmdefines the realm in which the identity is created.identity_typedefines the type of identity being created.admindefines thetokenidof the user with the necessary permissions to create; for exampleamadmin.
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
Theupdate 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
Thedelete 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.
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)
- Require Password Change at First Login and After Reset (LDAP attribute:
passwordchange,passwordmustchange) - Allow Users to Change Their Passwords (LDAP attribute:
pwdallowuserchange)
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
- Login to the OpenSSO console as administrator.
- Click the Access Control tab.
- Click the appropriate realm name.
- Click the Authentication tab.
- Click New in the Authentication Chaining section to create a new authentication chain.
- Enter a name for the chain and click OK.
For this example use idmauth. - On the new chain's Properties page, add the LDAP module as REQUIRED and click Save.
- Click Back to Authentication.
- Select the service just created as the value for Organization Authentication Configuration.
- Click LDAP in the Module Instances section.
- 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)
- Save the changes.
- Logout from the OpenSSO console.
- Use
/opensso/consoleto 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
amadminto 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,amadminwill no longer work. See Delegating Administrator Privileges for information on delegating administrative privileges to a group.
To Define Identity Manager URLs as Not Enforced
- Login to the OpenSSO console as administrator.
- Click the Access Control tab.
- Click the appropriate realm name and navigate to the Agents profile for the policy agent that protects Identity Manager.
- Under the agent profile, click the Application tab.
- Add the following URIs to the Not Enforced URIs property.
/idm/authutil//idm/authutil/*/idm/authutil/*?*
- Click Save.
- 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
gotoparameter. - The user identifier defined as the value of the
accountIdparameter
- Change to the
opensso/integrations/idm/jsps/directory in the decompressedopensso.zipto access the sampleChangePassword.jsp. - Modify the Identity Manager URL in the JSP based on your deployment.
- Copy
ChangePassword.jspto/web-container-deploy-base/opensso/config/auth/default/and to/web-container-deploy-base/opensso/config/auth/default_en/. - 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 underglassfish-home/domains/your-domain/generated/. - Restart the OpenSSO web container after making the changes.
Modifying the LDAP Authentication Module XML Service File
This procedure documents how to modifyLDAP.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
- Change to the
/web-container-deploy-base/opensso/config/auth/default/directory to access the deployedLDAP.xmlpage. - Open
LDAP.xmlin an editor and add the section of code displayed in yellow in admin_pwd_reset_ldap.html on the OpenSSO web site. - Change to the
/web-container-deploy-base/opensso/config/auth/default_en/directory to access the second copy ofLDAP.xmland make the same change. - 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 underglassfish-home/domains/your-domain/generated/. - Restart the OpenSSO web container after making the changes.
To Use the Sample LDAP.xml
- Change to the
opensso/integrations/idm/xml/directory in the decompressedopensso.zipto access the sampleLDAP.xml. - Replace your deployed
/web-container-deploy-base/opensso/config/auth/default/LDAP.xmlwith the sampleLDAP.xmlin two directories:/web-container-deploy-base/opensso/config/auth/default//web-container-deploy-base/opensso/config/auth/default_en/
LDAP.xmlwith the sampleLDAP.xmlyou will lose any custom changes made to the existingLDAP.xml. - 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 underglassfish-home/domains/your-domain/generated/. - Restart the OpenSSO web container after making the changes.
diff between both files and make the necessary changes manually.
Modifying the OpenSSO Login Page
This procedure documents how to modifyLogin.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
- Change to the
/web-container-deploy-base/opensso/config/auth/default/directory to access the deployedLogin.jsppage. - Open
Login.jspin an editor and add the two (2) sections of code displayed in yellow in admin_pwd_reset_login.html on the OpenSSO web site. - 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 underglassfish-home/domains/your-domain/generated/. - Restart the OpenSSO web container after making the changes.
To Use the Sample Login.jsp
- Change to the
opensso/integrations/idm/jsps/directory in the decompressedopensso.zipto access the sampleLogin.jsp. - Change the Identity Manager URL embedded in the sample
Login.jspto reflect the Identity Manager system URL of your architecture.
You can search for the string/idmto locate the URLs. - Replace your deployed
/web-container-deploy-base/opensso/config/auth/default/Login.jspwith the sampleLogin.jsp.
If you replace your existingLogin.jspwith the sampleLogin.jspthe 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.jspto incorporate requirements for other use cases related to the OpenSSO integration with Identity Manager.
- You will lose any custom changes made to the existing
- 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 underglassfish-home/domains/your-domain/generated/. - Restart the OpenSSO web container after making the changes.
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.- Access a URL protected by OpenSSO.
The OpenSSO login page is displayed. - 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
gotoparameter after the password has been successfully changed. - The value of the
accountIdparameter 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.
- The URL is the one configured in
B. Testing Password Expiration
Perform the following actions after the time the password should have expired, as defined in the password policy.- Access a URL protected by OpenSSO.
The OpenSSO login page is displayed. - 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
- Refer to your directory server documentation to enable audit and logging.
Monitor the directory server audit log as you finish the test. - Login as the directory administrator and change the password for a test user.
This simulates the password reset by a help desk administrator. - Verify that the user's
userPasswordattribute was modified and thepwdresetwas set to TRUE using the audit log.
Thepwdresetattribute 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 - Access the Identity Manager user URL.
You will be redirected to OpenSSO for login. - 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
gotoparameter after the password has been successfully changed. - The value of the
accountIdparameter 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.
- The URL is the one configured in
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.
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)
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
- Login to the OpenSSO console as administrator.
- Click the Access Control tab.
- Click the appropriate realm name.
- Click the Authentication tab.
- Click New in the Authentication Chaining section to create a new authentication chain.
- Enter a name for the chain and click OK.
For this example use idmauth. - On the new chain's Properties page, add the LDAP module as REQUIRED and click Save.
- Click Back to Authentication.
- Select the service just created as the value for Organization Authentication Configuration.
- Save the changes.
- Logout from the OpenSSO console.
/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
- Login to the OpenSSO console as administrator.
- Click the Access Control tab.
- Click the appropriate realm name and navigate to the Agents profile for the policy agent that protects Identity Manager.
- Under the agent profile, click the Application tab.
- Add the following URIs to the Not Enforced URIs property.
/idm/authutil//idm/authutil/*/idm/authutil/*?*
- Click Save.
- Logout of OpenSSO.
Modifying the OpenSSO Login Page
This procedure documents how to modifyLogin.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
- Change to the
/web-container-deploy-base/opensso/config/auth/default/directory to access the deployedLogin.jsppage. - Open
Login.jspin an editor and add the two (2) sections of code displayed in yellow in account_unlock_login.html on the OpenSSO web site. - 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 underglassfish-home/domains/your-domain/generated/. - Restart the OpenSSO web container after making the changes.
To Use the Sample Login.jsp
- Change to the
opensso/integrations/idm/jsps/directory in the decompressedopensso.zipto access the sampleLogin.jsp. - Change the Identity Manager URL embedded in the sample
Login.jspto reflect the Identity Manager system URL of your architecture.
You can search for the string/idmto locate the URLs. - Replace your deployed
/web-container-deploy-base/opensso/config/auth/default/Login.jspwith the sampleLogin.jsp.
If you replace your existingLogin.jspwith the sampleLogin.jspthe 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.jspto incorporate requirements for other use cases related to the OpenSSO integration with Identity Manager.
- You will lose any custom changes made to the existing
- 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 underglassfish-home/domains/your-domain/generated/. - Restart the OpenSSO web container after making the changes.
diff between both files and make the necessary changes manually.
Modifying the OpenSSO Account Lockout Message Page
This procedure documents how to modifyuser_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
gotoparameter. - The user identifier defined as the value of the
accountIdparameter
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
- Change to the
/web-container-deploy-base/opensso/config/auth/default/directory to access the deployeduser_inactive.jsppage. - Open
user_inactive.jspin 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. - 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 underglassfish-home/domains/your-domain/generated/. - Restart the OpenSSO web container after making the changes.
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
- Change to the
opensso/integrations/idm/jsps/directory in the decompressedopensso.zipto access the sampleuser_inactive.jsp. - Change the Identity Manager URL embedded in the sample
Login.jspto reflect the Identity Manager system URL of your architecture.
You can search for the string/idmto locate the URLs. - Replace your deployed
/web-container-deploy-base/opensso/config/auth/default/user_inactive.jspwith the sampleuser_inactive.jsp.
If you replace your existinguser_inactive.jspwith the sampleuser_inactive.jspthe 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.jspto incorporate requirements for other use cases related to the OpenSSO integration with Identity Manager.
- You will lose any custom changes made to the existing
- 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 underglassfish-home/domains/your-domain/generated/. - Restart the OpenSSO web container after making the changes.
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
- Configure the password policy and assign the policy to the test user.
This is done using the user data store. - Access a resource protected by OpenSSO to get redirected to the login page.
- 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. - 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 theuser_inactive.jsp. - Change your password.
Identity Manager determines the account from theaccountIDparameter 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 thegotoparameter.
To Test Physical Account Lockout
- Set the value of the
inetuserstatusattribute in the test user's profile in the user data store to Inactive. - Access a resource protected by OpenSSO to get redirected to the login page.
- Login to OpenSSO.
An error page will be displayed informing you that the account has been locked. - 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 theuser_inactive.jsp. - Change your password.
Identity Manager determines the account from theaccountIDparameter 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 thegotoparameter.
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
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
- Login to the OpenSSO console as administrator.
- Click the Access Control tab.
- Click the appropriate realm name and navigate to the Agents profile for the policy agent that protects Identity Manager.
- Under the agent profile, click the Application tab.
- Add the following URIs to the Not Enforced URIs property.
/idm/authutil//idm/authutil/*/idm/authutil/*?*
- Click Save.
- 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 deployedLogin.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
- Change to the
/web-container-deploy-base/opensso/config/auth/default/directory to access the deployedLogin.jsppage. - Open
Login.jspin an editor and add the five (5) sections of code displayed in yellow in self_registration_login.html on the OpenSSO web site. - 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 underglassfish-home/domains/your-domain/generated/. - Restart the OpenSSO web container after making the changes.
To Use the Sample Login.jsp
- Change to the
opensso/integrations/idm/jsps/directory in the decompressedopensso.zipto access the sampleLogin.jsp. - Change the Identity Manager URL embedded in the sample
Login.jspto reflect the Identity Manager system URL of your architecture.
You can search for the string/idmto locate the URLs. - Replace your deployed
/web-container-deploy-base/opensso/config/auth/default/Login.jspwith the sampleLogin.jsp.
If you replace your existingLogin.jspwith the sampleLogin.jspthe 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.jspto incorporate requirements for other use cases related to the OpenSSO integration with Identity Manager.
- You will lose any custom changes made to the existing
- 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 underglassfish-home/domains/your-domain/generated/. - Restart the OpenSSO web container after making the changes.
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
This procedure assumes that you have downloaded and installed NetBeans IDE and downloaded and installed the Identity Manager Plug-in for NetBeans.- 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. - From the NetBeans Project Window, right-click on the Custom Identity Manager Objects Node and select IDM > Open Object.
- In the Open Object dialog box, enter the object name End User Anonymous Enrollment and select OK.
- Right-click on the file in the Project Window and select IDM > Clone Object(s) to clone the object for safe keeping.
- Name the new object End User Anonymous Enrollment Orig.
- Click on the tab in the Editor window containing the file End User Anonymous Enrollment work flow.
This will put the file in focus. - Expand the tree in the Navigator Window to locate the Activity Assimilate User View.
- 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. - Save the changes.
- Right-click on the file and select IDM > Upload Object(s) to upload the file.
To Use the Identity Manager Debug Pages
- Login to the Identity Manager console as administrator.
- Go to the debug URL at
protocol://IDM-host-machine:port/idm/debug. - Select the object "Task Definition" in the list next to the "List Objects" button.
- Click on the "List Objects" button.
- Search for the object "End User Anonymous Enrollment" and click on its "edit" hyperlink.
You might first export the existing definition and save it. - 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. - 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
- Go to the OpenSSO login URL at
protocol://OSSO-host-machine:port/opensso/UI/Login. - Click the "Register User" button to register a test user.
- 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
- Login to the Identity Manager console as an administrator.
The "Create User" pending task is displayed as "Create User". - Navigate to the "Work Items | Approvals" tab.
- Select the provisioning task for the new user-id and click the "Approve" button.
- Confirm the approval.
- Logout of the Identity Manager console.
C. Verify Provisioning Of New User Account
- Login to the OpenSSO console as administrator.
- 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
- Go to the OpenSSO login URL at
protocol://OSSO-host-machine:port/opensso/UI/Loginand login as the new user.
A successful login indicates that the new user is active. - Logout of OpenSSO.
Posted at 09:06AM Sep 23, 2009 by Michael Teger in Sun | Comments[0]
A Good Morning for Single Logout Between Identity Manager and OpenSSO
This entry describe how to configure single logout between Identity Manager 8.1.0.5 (to be released sometime in October) and OpenSSO Enterprise 8.0. In the Identity Manager WAR, /idm is the base context of the deployment and thus the admnistrator area; /idm/user is the user area. You should be able to do the following:
- If logged out of the administration area, the person should be redirected to the same upon re-login.
- If logged out of the user area, the person should be redirected to the same upon re-login.
- Log in to the OpenSSO administration console as the administrator.
- Click the Access Control tab.
- Click the appropriate realm name and navigate to the agent profile for the policy agent that protects Identity Manager.
- Under the agent profile, click the Application tab.
- Click Logout Processing.
- Add the following map keys and values to the Application Logout URI property:
idm=/idm/logout.jspidm/user=/idm/user/userLogout.jsp
- Add the following map and key values to the Logout Entry URI property:
idm=/idmidm/user=/idm/user
- Click Save.
- Log out of OpenSSO.
- Log into Identity Manager.
- In the Identity Manager application window, click Logout IDM.
This should log you out of both Identity Manager and OpenSSO and then redirect you back to the OpenSSO login page. - Log in to OpenSSO.
You should be redirected to the specific Identity Manager administrator or user profile.
Posted at 09:34AM Sep 22, 2009 by Michael Teger in Sun | Comments[4]
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.
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.
- Installing Policy Agent 2.2 for Sun Java System Web Proxy Server 4.0
- For configuring the protected resource host machines and setting up load balancers for the policy agents, see Chapter 8 Configuring the Protected Resource Host Machines and Chapter 9 Setting Up Load Balancers for the Policy Agents of Deployment Example: Single Sign-On, Load Balancing and Failover Using Sun OpenSSO Enterprise 8.0
Posted at 12:00AM Sep 18, 2009 by Michael Teger in Sun | Comments[4]
Accessing OpenSSO from Outside a Secure Intranet (Put a Lock On It)
One of the major decisions in deployment planning is how to set up access to OpenSSO from outside a secure intranet. This information discusses two options: using a reverse proxy or using the Distributed Authentication User Interface (DAUI). Both options allow Authentication Service pages to be served to users over a firewall (for example) thus preventing direct access to OpenSSO by unauthorized users.
Using a Reverse Proxy
As an application proxy does, a reverse proxy acts as a gateway between a protected HTTP server and requests to the HTTP server that originate from outside the secure intranet. A reverse proxy is installed between the outer internet firewall and the inner intranet firewall - in what is referred to as the demilitarized zone (DMZ) - to prevent direct access to the OpenSSO configuration and user data stores by unauthorized users. A reverse proxy can be implemented as Sun Web Proxy Server 4.0.9 or as Sun Web Server 7.0 Update 3 or later with the reverse proxy plugin. It requires an SSL-enabled port for communication between the external client and the back-end OpenSSO server. The following diagram illustrates the deployment.
- Caching for improved performance When static content is cached, the reverse proxy would not forward a request for the content to OpenSSO; it would respond to the request by serving the content itself. This could lower the request load, thereby improving performance of the server and potentially lower response times to the client.
- Additional layer of security By introducing an additional layer of security, access to the OpenSSO server is further limited. This additional layer offers the opportunity to monitor traffic, to perform a wider set of checks (for example, malformed URL strings can be stopped at the proxy), and to react to attacks sooner.
- Persistent load balancing Configure the name of a sticky cookie or sticky URI parameter (in the reverse proxy configuration) to allow subsequent requests to stick to the same OpenSSO server that responded to the first request. Stickiness affects OpenSSO performance positively.
- Compression for speedy load times Outgoing traffic can be transparently compressed thus lowering total bandwidth requirements. A reverse proxy supports various compression levels and fragment sizes, allowing the administrator to select a level of compromise between speed and compression.
- Spoon feeding dynamic content Dynamically generated content can be returned from the back end server a little but at a time.
- Encryption and SSL acceleration.
- Installing Sun Java System Web Proxy Server
- Using the Java System Web Server as a Reverse Proxy for Improved Security: See chapters 3 and 4
- Configure reverse proxy in few seconds blog entry
- Agents Belong with OpenSSO and Reverse Proxy blog entry
Using OpenSSO Distributed Authentication User Interface
OpenSSO provides an authentication interface that can be deployed between the outer internet firewall and the inner intranet firewall - in the DMZ - to enable secure authentication communications to the OpenSSO server. Deploying the Distributed Authentication User Interface (DAUI) to one or more web containers within a non-secure layer eliminates the exposure of service URLs to the end user, and prevents direct access to the OpenSSO configuration and user data stores by unauthorized users. The following diagram illustrates the deployment.
- Eliminate all direct client/server traffic The DAUI receives all client authentication requests and, in turn, sends them to the back-end OpenSSO server, even eliminating encrypted traffic between the external clients and the OpenSSO server.
- Authentication Service support All authentication modules are supported via the DAUI.
- Dynamic customization of pages Each incoming request can be routed to different DAUI pages, dependent on the authentication chain or module being used. These DAUI pages are customized in the DMZ so access to the back-end OpenSSO server is not necessary.
Posted at 12:00AM Sep 14, 2009 by Michael Teger in Sun | Comments[0]
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.
- 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
Posted at 08:59AM Sep 04, 2009 by Michael Teger in Sun | Comments[0]
Addicted to Session Attributes in a SAMLv2 Assertion
So you want to copy session attributes and set them to a SAMLv2 assertion? Simply modify the attribute mapping for the identity provider or the remote service provider (you can do it using the OpenSSO console). The default OpenSSO SAMLv2 attribute mapper will find the appropriate attributes in the session and set them in the SAMLv2 assertion.
Now how about Puretone (aka Josh Abrahams featuring Amiel Daemion) and Addicted to Bass?Posted at 03:06PM Aug 31, 2009 by Michael Teger in Sun | Comments[0]
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.)
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.
Posted at 09:28AM Aug 24, 2009
by Michael Teger in Sun |
Comments[0]
St. Charles' JSP to Print Session Token Properties
Charles, a Sun QA engineer, recently posted a JSP to the OpenSSO mailing list that allows you to print out the properties (UserID, Principal, Client Address, and the like) populated in an SSOToken. I'm reposting the code here so it doesn't get lost in the maelstrom.
<%--
Copyright (c) 2007 Sun Microsystems, Inc. All rights reserved
Use is subject to license terms.
--%>
<html>
<head>
<title>Show Session Property</title>
<%@page import="com.iplanet.sso.*" %>
</head>
<body>
<%
SSOToken ssoToken = SSOTokenManager.getInstance().createSSOToken(request);
String value = "";
String propertyName = request.getParameter("propertyName");
if (propertyName != null) {
value = ssoToken.getProperty(propertyName);
}
%>
<h1>Session Property</h1>
<form action="show-session-property.jsp" method="POST">
Property Name <input name="propertyName" value="<%= propertyName %>" size="40"/>
<p/>
<input name="submit" type="submit" value="GetValue" />
</form>
<br/>
<%=propertyName%>: <%=value%><br/>
Principal: <%=ssoToken.getProperty("Principal")%><br/>
Principals: <%=ssoToken.getProperty("Principals")%><br/>
UserToken: <%=ssoToken.getProperty("UserToken")%><br/>
UserId: <%=ssoToken.getProperty("UserId")%><br/>
sun.am.UniversalIdentifier: <%=ssoToken.getProperty("sun.am.UniversalIdentifier")%><br/>
Organization :<%=ssoToken.getProperty("Organization")%><br/>
IndexType: <%=ssoToken.getProperty("IndexType")%><br/>
Service: <%=ssoToken.getProperty("Service")%><br/>
AuthType: <%=ssoToken.getProperty("AuthType")%><br/>
AuthLevel: <%=ssoToken.getProperty("AuthLevel")%><br/>
authInstant: <%=ssoToken.getProperty("authInstant")%><br/>
moduleAuthTime: <%=ssoToken.getProperty("moduleAuthTime")%><br/>
amlbcookie: <%=ssoToken.getProperty("amlbcookie")%><br/>
Host: <%=ssoToken.getProperty("Host")%><br/>
CharSet: <%=ssoToken.getProperty("CharSet")%><br/>
Locale: <%=ssoToken.getProperty("Locale")%><br/>
</body>
</html>
In honor of CMW, here's Jefferson Starship and the promotional film (cough, video) for their 1976 single, St. Charles. Although it's a great song, at 6 minutes and 40 seconds, I can see why it peaked at number 64. (Don't ask how I remember these things.)
Posted at 09:23AM Aug 20, 2009 by Michael Teger in Sun | Comments[2]
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.

- Working With the Entitlements Service
- Using the Federation Work Flows
- Using the Web Service Security Work Flows
- Displaying Realms
Posted at 10:22AM Aug 14, 2009 by Michael Teger in Sun | Comments[0]
