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.