RAP/Equinox Security Integration

Introduction

To ensure Eclipse is a secure runtime, enabling users and administrators to confidently work with the Eclipse client in environments where not all users and/or code sources are friendly. Providing integrated security functionality will allow Eclipse applications to protect their data, to authenticate and authorize valid users, and to protect against potentially malicious code packaged and distributed as plug-ins.

This will be done by enabling Java's standard security mechanisms within the Eclipse platform, defining new functionality where there are gaps in the available standard interfaces. Using Java's core standard interfaces will enable wider integration with code available throughout the Java community.

As Eclipse RCP has the same programming model as Eclipse RAP, we can adapt all the mechanisms that Equinox Security provides for our web application. You can also start the application with RCP or RAP as runtime.

Target

The target setup is straight forward. All you need is a plain RAP runtime and the org.eclipse.equinox.security bundle. You can either create your own target platform or use the predefined target definition that is located in the org.eclipse.rap.security.demo project (rap_security.target). Alternatively you can use the rcp_security.target to get the demo running as desktop application.

Be sure to not include the OSGi system bundle (org.eclipse.osgi) twice as this can lead to strange error messages upon starting

Login

To use Equinox Security / JAAS for authentication, we have to prepare several things in our application.

Login Modules

The first thing is to pick a proper authentication mechanism for our scenario. This could either be LDAP, Kerberos, a Keystore or, as in the example, a hardcoded list of users. The JRE itself already provides several implementations for LoginModules. The LoginModule is responsible for checking the given credentials against its source and tell if the authentication was successful. So the first step is to provide a JAAS config file to tell Equinox which login module we want to use.

DUMMY {
    org.eclipse.equinox.security.auth.module.ExtensionLoginModule required
        extensionId="org.eclipse.rap.security.dummy.dummyLoginModule";
 
};
 
UNIX {
    org.eclipse.equinox.security.auth.module.ExtensionLoginModule required
        extensionId="org.eclipse.rap.security.demo.unixLoginModule";
 
};

The configuration basically says that we want to use the ExtensionLoginModule which just acts as a proxy between JAAS and the Equinox Extension Registry. The real implementation here is defined by the extension (eg. org.eclipse.rap.security.dummy.dummyLoginModule, see plugin.xml).

   <!-- the extension prefix/plugin name is 'org.eclipse.rap.security.dummy' -->
   <extension
         id="dummyLoginModule"
         point="org.eclipse.equinox.security.loginModule">
      <loginModule
            class="org.eclipse.rap.security.dummy.DummyLoginModule"
            description="Dummy LoginModule">
      </loginModule>
   </extension>

As we now configured our login module, we need to tell Equinox Security to use exactly this configuration. This is the first thing in our application as we don't want to run any application without unpriviliged access.

  public Object start( IApplicationContext context ) throws Exception {
    String jaasConfigFile = "data/jaas_config.txt";
    BundleContext bundleContext = SampleBundle.getBundleContext();
    URL configUrl = bundleContext.getBundle().getEntry( jaasConfigFile );
    ILoginContext secureContext = LoginContextFactory.createContext( "DUMMY",
                                                                     configUrl );
    try {
      secureContext.login();
    } catch( LoginException e ) {
      // login failed
    }

Callback Handler

Now we have a login module configured that will check the credentials. But before we can check them, the user needs to provide them trough any form of I/O. In the case of RCP/RAP, we should show a dialog to enter the required informations. JAAS itself encourages a split between the authentication and how to provide the credentials. A CallbackHandler is responsible to provide the UI for the user while the LoginModule tells what it needs (eg. name and password). This way we can use any combination of LoginModules and CallbackHandlers. The mapping is defined by an extension of org.eclipse.equinox.security.callbackHandlerMapping.

An exemplary LoginModule and CallbackHandler are contained in the org.eclipse.rap.security.dummy project that is part of the example.

Subject

A Subject represents a grouping of related information for a single entity, such as a person. Such information includes the Subject's identities as well as its security-related attributes (passwords and cryptographic keys, for example) (see also the JavaDoc)

In order to get the currently logged in Subject, we can ask the JAAS API (only if the login was successful).

subject = Subject.getSubject( AccessController.getContext() );

Either the LoginModule or your application code can attach different Credentials in order to provide more accurate information about the user. In the Dummy LoginModule we attached for example to users Display to the authenticated subject.

Example

There are two example projects available. One is a small application that requires a login trough JAAS and provides a view to show the Subject and its attached Principles and Credentials. This project uses the second example that provides a pretty simple implementation of a LoginModule and a CallbackHandler.

You can download the example here.

Advanced concepts

Filtering the UI

In case you have different rights for different users and want to filter your UI according the the current user privliges, we can use the expression-based activity support in combination with your own SourceProvider that asks for Subject for its Principles.

References

• Equinox Security Project
• JCA/JAAS framework contribution
• Free JAAS Book
• expression-based activity support
• Using activities for user management