Riena/Getting started with Security

{{#eclipseproject:rt.riena}}

Riena Project ▶ Getting Started ▶ Security

Basic implementation concept of security in Riena

Security has many aspects. This document addresses authentication, authorization and session handling. Not included are SSL certificates or encryption in any way.

Java already provides a good set of classes for dealing with authentication and authorization

• Principal
• Subject
• Permission
• SecurityManager
• LoginModule
• CallbackHandler
• Callback

and policy providers for checking for permissions.

This all with some additional APIs and classes are what is called JAAS. Riena of course needs to use JAAS classes. There is also a new incubator project in Eclipse called equinox.security which is meant to create a wrapper for JAAS in the Eclipse world. Since equinox.security is not quite ready, Riena has chosen to base its implementation solely on JAAS and migrate to equinox.security later.

The challenge for Riena however is that JAAS was initially created for a distributed scenario where some of the code runs on the client and some code runs on the server. It can be used in distributed scenarios but has no dedicated support for distribution. Riena adds this distributed aspect.

Authentication

In Riena Authentication works in multiple steps:

• the client has its local login module (LoginModule Client) and its local callbackhandler (both standards from JAAS)
• the loginmodule defines the callbacks (name,password) for which it requires input
• the callbackhandler supplies the values for them (i.e. from the UI)
• the local loginmodule can not validate that the values are correct because it has no local authentication data

, so it calls the server by calling "clientLogin.login(callbacks)" which transmits the callback items to the authentication webservice on the server

• the authentication webservice now calls the login module on the server (LoginModule Server)
• this login module defines again callbacks for which it requires input (thats the JAAS procedure) hopefully they are equal to the ones that where defined on the client
• the authentication webservice supplies a generic callback to the loginmodule that satisfies the values for the individual callbacks from the values it got in the remote service call
• the login module on the server then does its normal authentication trick, by verifying the data against some authentication system
• if successful, it generates a Principal object (from JAAS) and adds it to the local Subject
• the Authentication Service, lets the SessionService generate a sessionid and stores the Subject in the session store
• it returns to the client with the Subject as method return value and with the session id as part of the remote service communication protocol

The following picture shows how that works.

Authorization

Once authenticated, the Subject is available on the client in the SubjectHolder which can be retrieved using the SubjectHolderService.

The sessionid that the authentication service generated is also transferred in each and every remote service call to the webservices. There a servicehook before the actual webservice invocation on the server that looks up the sessionid in the SessionService, retrieves the Subject and stores it in the SubjectHolder on the server. This way the webservice can retrieve the current Subject anytime during the webservice call.

The SubjectHolder is a singleton on the client and on the server it is threaded (one instance per thread). So each call on the server has a seperate SubjectHolder instance.

If run with SecurityManager (a JAAS feature), it necessary to activate RienaPolicy as policyprovider. RienaPolicy is then called by the SecurityManager for each Permission that needs to be checked. RienaPolicy retrieves the permission for the current Subject from the PermissionStore which retrieves it on request from the AuthorizationService.

It is easier to run the JVM without SecurityManager switched on and let the Business Logic only check for Business Permissions (and ignore FilePermissions and other standard Permissions for the moment). For that the Sentinel can be used. The Sentinel can be used anytime at client or server and checks whether the current Subject has a certain specified Permission. The reply is a boolean (true or false) and not an exception which is thrown by the SecurityManager.