Mrudul's web blog

Friday Jun 19, 2009

OpenSSO STS quick tips

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

Tuesday Apr 14, 2009

Tip on Custom authentication module UI

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.

Friday Mar 27, 2009

Web Services Security & Class Loader approach...

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"          
}; 

Monday Mar 23, 2009

Can not login as "amadmin" ? .... see why

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.

Friday Mar 20, 2009

How to use custom certificate for WSS samples ?

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.

Wednesday Mar 18, 2009

Customize Authentication UI / File lookup ...

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

Friday Nov 02, 2007

OpenSSO as STS at catalyst conference....

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-Trust / STS interop at Catalyst conference...

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

 

Friday Jun 29, 2007

JavaEE Security & AM preso at UC Davis

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

Identity Web Services - Hands-On Lab is now live ....

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

Monday Mar 12, 2007

OpenSSO Extensions are public

Check out  OpenSSO Extensions is Launched

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

 

Java Application Platform SDK Update 3 Preview is live ...

Java Application Platform SDK Update 3 Preview/Java EE 5 SDK Update 3 Preview/Java EE 5 Tools Bundle Update 3 Preview/GlassFish contest, etc. are now live.

Home page: http://java.sun.com/javaee/
New download "early access" page: http://java.sun.com/javaee/downloads/ea/

Try it out ...

 

More and more web services at JavaOne 2007

Web Services are everywhere ....

JavaOne 2007 complete session schedule is now available.

Session# Title
TS 4865 Takes two to Tango: Java Web Services and .NET Interoperability
TS 4948 Unleashing the Power of JAX-WS RI: Spring, Stateful Web Services, SMTP, and More
TS 6411 JSR 311: The Java API for RESTful Web Services
TS 8840 Services Interoperability with Java Technology and .NET: Technologies and Tools for Web 2.0
BOF 6412 Describing RESTful Applications: WADLing with Java

Friday Mar 02, 2007

WSS tutorial on SDN ...

tutorial on securing communications in Web services is on SDN now.

This uses and is provided via Sun Java System Access Manager, the Java Application Platform Software Development Kit (SDK) with Tools bundle (including NetBeans EP 5.5).

Wednesday Feb 28, 2007

About Me ...

A member of the Access Manager and Federation Manager engineering team, currently working as Project Lead for

- Web Services Security, focusing on Identity Web Services

- JavaEE SDK and NetBeans integration

Calendar

Feeds

Search

Links

Navigation

Referrers