JSecurity, an open source alternative java security framework

JSecurity

Introduction

Les Hazlewood  Co-Founder Jeremy Haile Co-Founder

Presentation Format

l         Topics areas introduced

l         Selected issues presented

l         Brief Demo

l         Q&A at the end

Tonight’s Topics

l         Project Background

l         Authentication (logging-in)

l         Authorization (access control)

l         Session Management

l         Framework Support

Project Background

l         Simplify or replace JAAS

l         Change group/role/permission assignments dynamically, during runtime

l         Access session data from multiple clients

l         Single Sign-On

l         Be free from J2EE / container-specific APIs (POJO-based)

Terminology

l         Subject – the party interacting with the system (person, 3rd party process, etc).

l         Principals – a Subject’s identifying attributes: username, user id, Social Security #, etc.

l         Credentials – values known only to a related Subject.  Used to verify identity.

Authentication

The act of verifying you are who you say you are.

l         Collect principals/credentials

l         Submit them to the system

l         If submitted credentials match those in the system, continue access.

l         If submitted credentials don’t match, allow retry or block access.

Authentication – Step 1  

1.  Collect princpals and credentials.

 

//collect username and password in a

//system-specific manner (HTTP request, GUI, etc)

String username = //get username

char[] password = //get password

Object token =

 new UsernamePasswordToken( username, password );

Authentication – Steps 2-4   

2 - 4.  Submit then allow or disallow.

try {

    getAuthenticator().authenticate( token );

} catch ( ConcurrentAccessException cae ) {

    //already logged in, system configured to disallow

} catch ( ExcessiveAttemptsException eae ) {

  //too many unsuccessful login attempts for the account

} catch ( LockedAccountException lae ) {

  //account currently locked – not usable

} catch ( UnknownAccountException uae ) {

  //no account for the submitted username

} catch ( IncorrectCredentialException ice ) {

  //submitted password was incorrect for the account

} catch ( AuthenticationException ae ) {

  //unexpected authentication problem

}

//No problems, show authenticated view…

 

Authenticator – single-method interface:

public AuthorizationContext authenticate(

    Object authenticationToken )

    throws AuthenticationException;

 

1.         Executes log-in attempt.  Implementation of this interface usually provides PAM behavior.

2.         If unsuccessful, handle in application-specific manner

3.         If successful, a data context is returned that is associated with the logged-in account.

 

The AuthorizationContext is part of the Authorization presentation.

Default Authenticator implementation in the JSecurity RI is the ModularAuthenticator.

 

l         Implements PAM (Pluggable Authentication Module) functionality.

l         Utilizes a configured set of

AuthenticationModules

l         Out of the box module implementations for Memory (RAM), LDAP, ActiveDirectory, JDBC, and others.

l         Create your own for application-specific data access (e.g. Hibernate or JPA)

Authorization

Once identity is validated, authorization is the process of determining access control – i.e. “who can do what”, or “who can do which actions”.

 

l         Generally assumes Realm-based approach: an aggregation of users (a.k.a. Subjects), user groups, roles, and permissions.

l         JSecurity can work with any data model, even if yours doesn’t coincide with these assumptions

Permissions

l         The “what” of the application.

l         Most atomic element of a security system.

l         Describes behavior for a type of object

l         Does not maintain information about “who” can perform such behavior.

 

Example:  A PrinterPermission instance defines if a printer can be accessed or not.  It does not associate who can or cannot access that printer.

Roles

l         A named collection of Permissions

l         Allows behavior aggregation

l         Enables dynamic (runtime) alteration of user abilities.

l         Most similar to what we see in Windows or Unix user “groups”.

 

Example:  An “Administrator” role might have the AllPermission.

 

l         Still does not define “who” can do what - just organize multiple abilities.

Users

l         The “who” of the application.

l         What each user can do is defined by their association with Roles.

 

Example:  A user “has a” collection of Roles.  If one or more of those roles “has a” PrinterPermission, then that user can print to a specific printer.

Groups

l         Group of Users.

l         Each Group “has a” collection of Users.

l         Each Group “has a” collection of Roles.

l         Users in a group have the group’s roles by implicit association.

l         Primarily a convenience mechanism (user-to-role associations are usually good enough for most applications).

Authorization

Multiple means of checking access control:

l         Programmatically

l         JDK 1.5 annotations

l         JSP TagLibs

l         XML Config (coming soon, container-dependent)

Programmatic Authorization

Checking for a particular Role:

 

//get AuthorizationContext for the current user (i.e. the user associated with the currently executing thread).

AuthorizationContext authzCtx =

    SecurityContext.getAuthorizationContext();

 

If ( authzCtx.hasRole( “administrator” ) {

    //do one thing (show a special button?)

} else {

    //do something else (don’t show the button?)

}

Checking for a particular Permission:

 

//get AuthorizationContext for the current user

AuthorizationContext authzCtx =

    SecurityContext.getAuthorizationContext();

 

Permission printPermission = new PrinterPermission( “laserjet3000n”, “print” );

If ( authzCtx.implies( printPermission ) {

    //do one thing (show the print button?)

} else {

    //do something else (don’t show the button?)

}

Annotation Authorization

Role-based:

 

//next code block will throw an

//AuthorizationException if the caller doesn’t

//have the ‘teller’ role:

@RolesRequired( “teller” )

public void openAccount( Account acct ) {

    //do something in here that only a teller

    //should do

}

 

Permission-based:

 

//next code block will throw an

//AuthorizationException if none of the caller’s

//roles imply the specified AccountPermission

@PermissionsRequired(

     type=com.company.security.AccountPermission,

     actions=“create”

 )

public void openAccount( Account acct ) {

    //create the account

}

 

JSP TagLib Authorization

<%@ taglib prefix=“jsec” uri=http://www.jsecurity.org/tags %>

 

<html>

<body>

    <jsec:hasRole name=“administrator”>

        <a href=“manageUsers.jsp”>Click here to manage users</a>

    </jsec:hasRole>

    <jsec:lacksRole name=“administrator”>

        No user admin for you!

    </jsec:hasRole>

</body>

</html>

Session Management

l         Impetus for creation – Heterogeneous client access

l         Simplified Configuration

l         POJO/J2SE based (IoC friendly)

l         Not bound by client or specification protocol.

l         Can be used in Single-Sign On implementations

l         Temporal-based record (start, stop, last access times).

l         Event-trigger support

l         IP address correlation (if needed)

l         Inactivity and expiration support (touch() method)

l         Retains HTTPSession methods you’re comfortable with (get/set/remove Attribute methods)

l         Session Management is typically transparent to application developers

l         Interceptor/AOP mechanisms to create, associate, and maintain Sessions

l         Event support enables transparent activity logging.

l         Session Data (Attributes and metadata) can be stored anywhere – in a database, on the file system, in memory, a distributed cache, etc. (DAO transparency to back-end store).

 

A SessionFactory allows you to create and acquire Sessions explicitly.

 

Creating a Session:

//get app-configured factory

SessionFactory factory = getSessionFactory();

 

//get InetAddress from web request,

//local machine, or other means

InetAddress hostAddress = xxx;

Session s =

    factory.start( hostAddress); 

 

Acquiring an existing Session:

//get session ID from a web

//request, an applet parameter

//system property, etc.:

Serializable id = getSessionId();

//acquire the session:

Session s = factory.getSession ( sessionId );

 

The previous slides’ work is better left to framework classes such as AOP interceptors and Servlet filters.

 

If the application is configured this way, an application developer can generally assume a Session exists:

//Get the session for the currently executing

//user’s thread:

Session s = SecurityContext.getSession();

String currentTabID = (String)s.getAttribute( “currentTabID” );

Logging-out

When done, a programmer can invalidate the current user’s context (and Session if it exists):

 

SecurityContext.invalidate()

 

App-specific log-out logic is can be executed in any number of ways:

l         Execute explicitly either preceding or after this call

l         Listen for the stopped SessionEvent and trigger the logic based on the event.

l         Both.