Mrudul's web blog

Get the answer here ...

You can get the plain text password entered by user for OpenSSO server login / authentication, at agent / client side with following configuration steps :

1) Add "com.sun.identity.wss.security.useHashedPassword=false" property at OpenSSO server side and agent/client side.
2) Add a new value "com.sun.identity.authentication.spi.WSSReplayPasswd" in Access Control -> Top Level Realm -> Authentication -> Advanced Properties -> Authentication Post Processing Classes, on OpenSSO server side.
3) Make sure you have same value for "am.encryption.pwd" on OpenSSO server side and agent/client side.

After this, following can be executed on agent/client side :

String encryptedPassword = ssoToken.getProperty("EncryptedUserPassword");
String clearPassword = Crypt.decrypt(encryptedPassword);

Check out new OpenSSO SDN article :

Enabling Web Service Security With OpenSSO WSS Agent

Well...here is your answer .... Try new "Resource / IP / Environment based Authentication" feature in OpenSSO Express build 8 and above, by following the detail SDN article.

If answer is yes, then OpenSSO has a solution now, that works seamlessly on all containers supporting JAX-WS (which is the base for any Web Service)... including Glassfish, Tomcat, JBoss, WebLogic and WebSphere.

Download new Web Service Security Agents openssowssagents.zip, extract the zip and follow top level README file.
To try out included Web Service Client and Web Service Provider samples, follow samples/README file.

Check out OpenSSO STS related cool quick tips at OpenSSO wiki ... 

You could have pretty extensive UI generated for custom authentication module based on the callbacks defined in the module's xml properties file. Module xml file defines the set of callbacks (based on Auth_Module_Properties.dtd) and since Auth UI is completely driven by callbacks, it renders these callbacks via JSP pages.

OpenSSO support all standard JAAS callbacks + additional ones that we have implemented like "HttpCallback", "RedirectCallback" and "PagePrpertiescalback". As long as custom authentication module uses these callbacks in its xml file, Auth UI layer can understand and render those. With this set of callbacks, you can achieve extensive UI where you can exercise HTTP protocol level negotiation parameters, redirect to third party urls, change page branding like images, headers, templates (jsp pages), page time outs, etc.. in addition to what stand JAAS callbacks support. You can also do multi-step authentication if custom authentication module defines multiple set of "Callbacks" elements for multiple page orders or page states.

But if custom auth module wants to define its own custom callback, then Auth UI would not be able to render that callback since it would not know about it. If this case is required then one can use auth remote API to authenticate to custom auth module and process and render that custom callback in the client application itself. Auth remote API does support custom callbacks communication from auth module to the API caller, as per remote-auth.dtd.

OpenSSO provides functionality of securing Web Services on various platforms.

This feature mainly includes :
1.Security Token Service
OpenSSO server is hosted as Trusted Authority being Security Token Service.

2.Web Services Security Agents
SOAP providers or plugins based on JSR 196 SPI and supported in Glassfish (Sun App Server 9.0 onwards) container. These plugins as the interceptors that secure and validate web services communication.

3.Client API
WS-Trust client API to get security tokens from OpenSSO hosted STS end point.
Client API to secure and validate web service request / response, using WS-Security tokens (SAML, X509, UserName, Kerberos, etc.)

OpenSSO uses Metro web services framework for WS-Trust and WS-Security (unified JSR 196) functionalities.

OpenSSO is built, shipped an deployed as single Web Application (.war file) and this web application is supported on all of the following containers :

1.Sun Java System Application Server 9.1 Update 1 and Update 2
2.Glassfish Application Server V2 UR1 and UR2
3.Sun Java System Web Server 7.0 Update 3
4.Apache Tomcat 5.5.x and 6.x
5.BEA WebLogic Server 9.2 MP2
6.BEA WebLogic Server 10.x
7.Oracle Application Server 10g
8.IBM WebSphere Application Server 6.1
9.Apache Geronimo Application Server 2.1.1
10.JBoss Application Server 4.x

Requirement :

OpenSSO web application when deployed as server (hosted STS end point) should be supported in all above mentioned 10 containers, with underline Metro web services framework for WS-Trust and WS-Security functionalities. Also for such support, we should not require any container specific settings / changes in either OpenSSO web application or in the container itself.

Problem :

OpenSSO uses underline metro jar files (webservices-api.jar, webservices-rt.jar, webservices-tools.jar, webservices-extra-api.jar, webservices-extra.jar, etc.) to build Web Services Security functionality on top. All these jar files are using latest 2.1 version of jaxb, jax-ws, saaj, etc. in OpenSSO web application (these jar files are bundled in the web app, under WEB-INF/lib). But OpenSSO web app has to run on all above 8 web containers which includes older versions (2.0) of jaxb, jax-ws, saaj, etc. jar files and keep them in container's global class path.
Hence there is a conflict.

Solution :

Implement OpenSSO specific Classloader logic to load web app's WEB-INF/lib jars (web services jar files of jaxb 2.1 version) in separate classloader (parallel to the container's classloader) and not conflict with web container's classpath and its classloader.

Theory :

STS entry or first invocation points from OpenSSO's web.xml bootstrap FAMClassLoader before invoking any Metro (web services relates) class files.

The first thing we check in FAMClassLoader is if Container classloader can load everything we need correctly, i.e. 2.1 classes. So we first check if it's loading JAXB API 2.1. This is done by trying to get resource (ClassLoader.getResource) of the class that is new in 2.1 version (new webservices-*.jar files). If this check detected that our environment (Container classloader) is already loading JAXB API 2.1 for us, then there's nothing else needed. We just proceed with the Container classloader to load all the classes.

But if this check detected that our environment is loading 2.0 API, then the real functionality of FAMClassLoader starts. First, we create a MaskingClassLoader that selectively disables (masks or hides) delegation of JAXB 2.1 API and everything that depends on it (like all the RI code) to the parent (Container) classloader.

/**    
* The list of package prefixes we want the    
* {@link MaskingClassLoader} to prevent the parent    
* classLoader from loading.    
*/   
public static String[] maskedPackages = new String[]{
"com.sun.istack.tools.",       
"com.sun.tools.jxc.",       
"com.sun.tools.xjc.",       
"com.sun.tools.ws.",       
"com.sun.codemodel.",       
"com.sun.relaxng.",       
"com.sun.xml.xsom.",       
"com.sun.xml.bind.",       
"com.sun.xml.bind.v2.",       
"com.sun.xml.messaging.",       
"com.sun.xml.ws.",       
"com.sun.xml.ws.addressing.",       
"com.sun.xml.ws.api.",       
"com.sun.xml.ws.api.addressing.",       
"com.sun.xml.ws.server.",       
"com.sun.xml.ws.transport.",       
"com.sun.xml.wss.",       
"com.sun.xml.security.",       
"com.sun.xml.xwss.",       
"javax.xml.bind.",       
"javax.xml.ws.",       
"javax.jws.",       
"javax.jws.soap.",       
"javax.xml.soap.",       
"com.sun.istack.",       
"com.sun.identity.wss.",       
"com.sun.identity.wssagents.",       
"com.sun.org.apache.xml.internal.",            
"com.sun.org.apache.xpath.internal.",       
"com.sun.org.apache.xalan.internal.",       
"com.sun.org.apache.xerces.internal.",       
"com.sun.identity.saml.xmlsig.",       
"com.sun.identity.xmlenc.",       
"com.sun.xml.stream."   
};


Then we create an URLClassLoader beneath it, by specifying the jar files of the JAXB 2.1 APIs. Now we have a classloader that can load JAXB API 2.1 and its RI without interference from the existing environment.

/**    
* The list of jar files to be loaded by FAMClassLoader.    
*/   
public static String[] jars = new String[]{       
"webservices-api.jar",       
"webservices-rt.jar",       
"webservices-tools.jar",       
"webservices-extra-api.jar",       
"webservices-extra.jar",       
"opensso.jar",       
"openssowssproviders.jar",       
"xalan.jar",       
"xercesImpl.jar",       
"openfedlib.jar"          
}; 

If you can not login as "amadmin" to OpenSSO server, you may want to check following :

• Have you configured OpenSSO instance to point to same DIT as AM 7.x, and used different encryption key than the original AM 7.1 server ?

You have to use same encryption key here.

• Are you authenticating "amadmin" with its password in OpenSSO's user store ?
  

"amadmin" and its password will be first authenticated against configuration store, i.e. this user and its password should match the "amadmin" user and its password in OpenSSO's configuration store (special users under IdRepo service).
Actual auth module store and / or user store and configuration store could be different as long as above is successful.

• Are you authenticating "amadmin" with its password to sub-realm ?

"amadmin" can only login to top level or root realm.

These are the simple steps to follow if you want to use your custom certificate for Web Services Security samples (from openssoproviders.zip) :

Note : Out of box, OpenSSO uses "test" certificate and its alias in bundled keystore.jks. The keystore or certificate store password and key password is "changeit".

1) Create custom certificate and custom keystore.jks using "keytool"
keytool -genkey -keyalg rsa -alias custom_cert_alias -dname "CN=custom.sso.apps.testbed, OU=Custom_org, O=Custom_company, L=Custom_city, ST=Custom_state, C=Custom_country" -keypass changeit -keystore keystore_custom.jks -storepass changeit
This creates keystore_custom.jks with "custom_cert_alias" certificate.

2) Replace server keystore
cd <opensso config dir>/<opensso_deploy_uri>
cp keystore_custom.jks keystore.jks

3) Replace client keystore
wherever you have unzipped openssoprovider.zip
.../resources/
cp keystore_custom.jks keystore.jks

4) Changed key alias from "test" to "custom_cert_alias" in Server -> Configuration -> Sites and Servers -> Default server configuration

5) Changed key alias from "test" to "custom_cert_alias" in Client <GF install dir>/addons/opensso/AMConfig.properties
Make sure keystore location is pointing to (3)

6) Changed key alias from "test" to "custom_cert_alias" in wsc, StockService (if you have this one), wsp agent profiles

Restart the GF container and you can exercise StockQuoteClient sample successfully with X509 token and signing on. Also verify that it is using custom certificate.

Authentication UI Customization based on directory locations :

Location for Customized Auth UI JSP pages and Auth Module Properties (xml) files:

The Customized Web UI JSP templates and Authentication Module Properties XML File are located by the Authentication Service based on a certain hierarchy.

The first match of the File is returned to the user. The following parameters are considered for location a file:

• Organization/SubOrganization - this is the organization/sub-organization of the request.
• Locale - Locale of the request
• Client Path - Client Type information of the request
• Service Name (serviceName) - Service name for service based authentication

Note: the Locale ,Client Path ,Service Name are optional

The file search path is as follows (under deployed opensso web app i.e. ....opensso/config/auth/) :
default_locale/orgPath/filePath/fileName
default/orgPath/filePath/fileName
(where "default" is default / root realm)         

where
orgPath = services/subOrg/sub-subOrg
filePath = clientPath + serviceName
clientPath = clientType/sub-clientType
fileName = module xml file / auth UI JSP file

Example :
locale = en
subOrg = solaris
clientPath = html/nokia/
serviceName = paycheck
fileName = Login.jsp

                FileLookup for the above would be (in the order below):

                default_en/services/solaris/html/nokia/paycheck/Login.jsp
                default_en/services/solaris/html/nokia/paycheck/Login.jsp
                default_en/services/solaris/html/Login.jsp
                default_en/services/solaris/Login.jsp
                default_en/html/nokia/paycheck/Login.jsp
                default_en/html/nokia/Login.jsp
                default_en/html/Login.jsp
                default_en/Login.jsp

                default/services/solaris/html/nokia/paycheck/Login.jsp
                default/services/solaris/html/nokia/paycheck/Login.jsp
                default/services/solaris/html/Login.jsp
                default/services/solaris/Login.jsp
                default/html/nokia/paycheck/Login.jsp
                default/html/nokia/Login.jsp
                default/html/Login.jsp
                default/Login.jsp

Federated Access manager 8.0 product (based on OpenSSO project) demonstrated its functionality as IDP, enabling Managed InfoCard provider and Security Token Service end points with Windows CardSpace Identity selector, at Burton group's Catalyst conference (Barcelona 22-25 October, 2007) IOP event.

The SUN's OpenSSO IDP/STS presentation and IOP results shows the interoperatibility between multiple Identity Selectors and Relying Parties.

WS-* technologies were everywhere in Burton group's Catalyst conference (Barcelona 22-25 October, 2007) and in IOP event, along with InfoCard selectors... with focus on WS-Trust, WS-SecurityPolicy, WS-Security, WS-I BSP Security tokens, etc.

The SUN's OpenSSO IDP/STS presentation and IOP results talk about more...

 

Presented 'Java EE Security using Access / Federation Manager' at UC Davis 2007 IT Security Symposium.

Hands-On Lab went live on the Identity Management home page :
http://developers.sun.com/identity/

Hands-On Lab: Securing Identity Web Services (LAB-5410)
<http://developers.sun.com/learning/javaoneonline/j1lab.jsp?lab=LAB-5410&yr=2007&track=8>

This lab shows how to use OpenSSO (Sun Java System Access Manager) deployed within the
Java Application Platform SDK to configure authentication source and identity repositories.
It demonstrates how Web services can be secured using standard security mechanisms.
(SDN registration (free) required.)

Check out  OpenSSO Extensions is Launched

So include more and more innovations to OpenSSO, quickly and easily.