Difference between revisions of "Security: JCA/JAAS framework contribution"
(New page: == Summary == This document details the IBM Lotus code contribution that contains enhanced support for the JCA architecture in an Eclipse environment, and a login framework that is based ...)
Revision as of 12:55, 18 July 2007
This document details the IBM Lotus code contribution that contains enhanced support for the JCA architecture in an Eclipse environment, and a login framework that is based on Java's login infrastructure - JAAS. See here for more information on JCA, and here for info on JAAS.
Getting the code
Pull the following plug-ins from equinox-incubator/security:
The code in org.eclipse.equinox.security.boot contains code that proxies JCA & JAAS related provider method calls to implementations that reside in various plug-ins, and must be on the extension or boot classpath of the application. Export the project to the filesystem as a jar and put it explicitly in the default VM arguments of the JRE with -Xbootclasspath/a:<path-to-boot-jar>. Otherwise remember to reference the Jar explicitly your Run... configurations.
- We intend to integrate this into OSGi and/or the Launcher. Ideas welcome, bug here: 196988.
One current issue is that the Equinox Boot Delegation changes cause trouble because we have some packages that span the boot Jar and the proxy which it is connected to. We'll fix this ASAP: 196987. For now, set -Dorg.osgi.framework.bootdelegation=* in your Run... as well.
Running the tests
The JUnit tests should ensure that the proxy is set up correctly and will properly handle requests for LoginModule implementations.
Create a 'JUnit Plug-In Test' Run... that specifies the org.eclipse.equinox.security.junit.SecurityTestSuite class in the org.eclipse.equinox.security.junit plug-in. Set it as a 'Headless Mode' application, and pare the plug-in set down to the minimum required on the Plug-ins tab. Remember to set -Xbootclasspath/a:<path-to-boot-jar> and -Dorg.osgi.framework.bootdelegation=* in the VM arguments. You will get NoClassDefFound errors regarding the provider if it is not setup correctly.
Running the sample application
There is sample application in the org.eclipse.equinox.security plug-in. It contains a standalone RCP application that uses a platform-wide JAAS javax.security.auth.LoginContext to perform a login, and then runs the Workbench using the result of that login (a javax.security.auth.Subject). A simple UI then allows inspection of the Subject.
Create an 'Eclipse Application' Run... that specifies the org.eclipse.equinox.security.sample.authProduct product. As with the tests, remember to set -Xbootclasspath/a:<path-to-boot-jar> and -Dorg.osgi.framework.bootdelegation=* in the VM arguments. The application installs the provider in AuthApplication.java like so:
Security.setProperty( "login.configuration.provider", "org.eclipse.equinox.security.auth.ConfigurationProvider");
The name of the login configuration to use for login is specified in the plugin_customization.ini file in the data/ subdirectory of the sample plug-in. By default, the sample uses a built-in configuration named 'KeyStore' that will create and authenticate against a .keystore file in the user's workspace. There is also an XML based login configuration provider provided in the system, and a sample configuration is available in the jaas_config.xml file in the data/ subdirectory. In AuthApplication.java, this line:
Security.setProperty( "login.config.url.1", AuthAppPlugin.getDefault( ).getBundle( ).getEntry("data/jaas_config.xml").toExternalForm( ));
sets the location of the XML configuration file. Modify the plugin_customization.ini file to specify 'Win32' to exercise the Windows LoginModule referenced in the sample XML configuration - note that this only works with the Sun JRE for now.
Comments, criticisms, etc
Comments, criticisms, bugs, requirements, enhancements etc are all welcome. We'll be watching the equinox-dev mailing lists as well as BugZilla.