Login Security

• Allows a user to register and obtain a username and password
• Provides required fields checking facilities on the quality of the registration
• Mechanism to extend default user fields in Registration Process
• Checks for confirmation of password before making the account active
• Confirms registration by sending a welcome email to the user including the username and password. This email is user-definable, which allows for customizable message
• Method to approve membership before joining fully
• Alternative mechanism to log in with the user's email and password
• Function for users to change their password once they have logged in
• Function for users to update their user profile such as address and contact information
• Function for user to log out
• Mechanism to verify the identity of users by email if a user forgets their login and/or password - and to email the user their login and a new password
• User's Address and contact information is available for contact member directory
• Ability to add Users to User Groups which is used to define user roles.
• Facility to grant Database Object Security to User Groups.
• Provides user authentication for all member-related services
• Provides user membership that can be extended with additional components. i.e. by other applications such as eContent's ability to protect resource access and prevent non-members seeing content , or through custom development of Expresso based applications

If you want to have to avoid the Expresso Login mechanism, then it boils down to this. Servlets depend on a "session" linking the client to the server. Expresso login mechanism simply stores a username in the session, after authenticating it. So, if you need to use some other login mechanism, what'd you'd do is write a class that intercepts a new session being created, and then set the username variable just like Expresso's Login controller does.

Authentication

The first layer of security in Expresso is the Authentication - this is the process of identifying the user and verifying that the user is in fact who they say they are: At it's simplest level this is done via a user name/password login process, but is "pluggable" to allow more sophisticated authentication schemes, integration with LDAP servers, etc to easily be added.

If appropriate, authenication information can be stored on the client as a cookie to enable the user to bypass the manual login process when they next visit the application.

Login requires a login name and password for all secured functions. Some functions may be unsecured - that is, any user may access them without logging in, but ordinarily most functions will require a login. If the user goes directly to the URL of a function that requires a login, but has not yet logged-in, they will be presented with the login screen, and upon a successful login will continue on to the function they originally selected.

A successful login establishes a session - a session is maintained until the user either logs out, leaves their browser (e.g. exits the browser application), or until the server is restarted for some reason. (Sessions will also time out after a period of inactivity).

Expresso also has an auto-redirect feature to redirect the user to where they logged in from.

Authorization

Once a user is identified and associated with a session, their authorization is determined by identifying which user groups a user belongs to. Similar to user groups in the Unix environment, or to "roles" as defined by many application servers, groups can however be nested within other groups to make management of extremely large user communities very efficient. Permission is then granted at any of several levels to the group, and thus to the members of the group. Permissions can be assigned at:

1. Database Object Level: Assigning permission to add/update/delete/search for any database object (table) in the application.

2. Controller Level: Allowing access to all or selected "states" of each Controller in the application, controlling precisely which functions specific groups of users are allowed to perform.

3. Job Level: Allowing access to specific background jobs

4. Custom level: Allowing access at a customized level for a specific application: for example, allowing users to subscribe to different discussion groups for a forum application (such as eForum).

Encryption

Both basic and sophisticated encryption is available for securing any data within the system, so that only authorized users can access the specified data. This deals with the issue of users gaining access to the database server directly and attempting to bypass application security in this manner.

Filtering

Field data entered into an application can have "filters" applied to it automatically to avoid attacks on system security by embedding information in the entered data (such as Javascript or other scripting languages).

Administrative Security

Any of the table maintenance/administrative functions can be secured. For all table maintenance functions, security is achieved by granting group access to certain database objects, as required for the particular function. Database Object Security can be granted in any of the following degrees:

• Once appropriate administrative privileges have been granted to a group, it is then straightforward to add administrative users to that group as required.
• A special group called "Everybody" is recognized automatically by the system. This group can be used to grant global permissions, such as universal ability to read the job queue, for example.  Use extreme caution in granting access to the Everybody group.
• For a user to access the privileges assigned to his/her group, they must log in   (separate from their regular network login). A user who has not yet logged in is assigned the user login name "Anonymous", which is a member of the "Everybody" group only.
• A login is valid until the web browser is closed or until the servlet-runner process is restarted. Passwords may be set explicitly via the user administration program, or may be changed by the individual user on the Login web page using the appropriate form.
• Logging in is only necessary for users not already authenticated by a system logon (i.e. Unix logon or NT domain users).

Database Object Security

All database objects (which, as we discussed, may or may not have a one-to-one relationship with database tables) have security attributes. A group of users can be granted permission to any combination of Search, Add, Update or Delete security.

This security information is, for performance reasons, read into a cache when the first database connection is made & read from that cache until a change requires it to be re-read. Changing any of the user/group or security tables will cause security to be re-read, and this re-reading takes place as a background thread until it is complete - then the old security information is replaced in a single operation - this prevents partially-read security information causing problems.

Application Security

Any object (servlet or otherwise) can be registered as an application. Applications then have security applied to them in a manner very similar to that of database objects. In addition, applications may have a more detailed level of security, called application methods: For example, if a user is allowed to use the ledger posting application, they might be able to post only their own transactions, or to post any transactions. These "methods" are application specific.

The Expresso Framework provides a complete system for applying all of these security facilities, ready to add your own application-specific objects into.

LDAP Integration

A LDAP component will be available as part of the Expresso Enterprise which includes commercial extensions to Expresso. Individual components of Expresso Enterprise may be purchased separately. A release of Expresso Enterprise will be available sometime in the next quearter.

Enables a Tomcat 4.x based Expresso solution to handle single sign on (SSO) for all types of web content, from jsp to html/doc/etc, using an LDAP-server. It also enables SSO for multiple web applications under a single Tomcat instance.

Users: Can change their password transparently using regular Expresso functionality.
Admin: Uses export tool after setting up or changing groups. User information is handled transparently.

With some minor coding this can be made to work under any J2EE compliant web container.

Container Security Authentication Integration

CheckLogin has been modified to allow for Expresso to get the currently logged in user as far as the container is concerned and hook into it's own Security system this way. Expresso now will utilize getUser() from the servlet engine to attempt to log the user in that way. It uses standard Servlet API's so it shouldn't be a problem for various Servlet engines. The roles the user receives are still Expresso-based. This feature is marked Experimental in the current release.

Even with container security integration, we will keep the current database tables as the default implementation (although pluggable security matrices are in the works) since they've been SO convenient and nice to work with. As of this writing , sometimes container integration can be a major hassle, especially when switching from container to container. Staying container independent at this phase, and slowly integrating in as container spec conformance comes about seems like an appropriate plan.

SSL Integration

As of Expresso 5.0, the ability to utilize the ability to enter and exit SSL pages has been automatically added. Expresso can now set various states in a controller as secure, by simply in the constructor, call myState.setSecure(true). If this is true, then Expresso will automatically redirect to SSL protocol (or back) without losing session! This is the most critical component in an eCommerce application. The best part about it is that this is backwards compatible. If you do not set useSSL in your context configuration, then even if a state is 'secure' then Expresso will NOT attempt to use SSL.

SSL is an encrypted protocol that allows you to pass data between the webserver and web client without the myriad of computers sitting between you and the webserver being able to find out what communication took place. This is extremely important for any situation where you may have information that you do not want other people to steal just by listening in on your web transaction. Examples include Credit Card information, passwords, personal registration information, and many other possibilities.

Why isn't everything done over SSL then? The biggest answer is price. To set up a secure webserver you have to do several things. First is acquire a digital certificate from a certificate authority such as http://www.verisign.com or http://www.thawte.com/ These cost money for each server you run this on. The more important aspect, however, is that encrypted connections require A LOT more CPU power than a standard non-encrypted password. If a site is completely encrypted, it will be must less responsive than a non-encrypted site.

Therefore, before you really use SSL, you need to decide where in your application you require it. Examples are login pages, online store checkout systems. For the latter example, for instance, you wouldn't necessarily want to encrypt all data between you and the customer concealing what was in their shopping card. But you WOULD want to encrypt the page where the customer includes the credit card.

One final consideration when setting up Expresso security is that you will want both the page that prompts for the secure information AND the page that processes that secure information encrypted over SSL. Otherwise Expresso's features will be unable to automatically compensate for the user's data entry.

For more information see the Expresso Developers Guide (EDG) which covers the basic installation concepts as it applies basic expresso configuration, and how to utilize these new features in your own code.

Conclusion

Here are some helpful hints to follow when starting to use Expresso Security:

1. Definitely read the guide, Expresso Registration and Login.
2. Make a copy of the existing Login and Registration controllers to your code base (or modify the existing ones)
3. Modify/add mappings in struts-config.xml or your own config file to change the use of the /Login.do and /Registration.do mappings (if your wanting to change the look and feel, change the associated JSPs also).
4. Be careful of the inner-dependencies between LoginController and RegistrationController. In some instances, the transitions are called by class name, so you'll have to update the location of the controllers if you migrate the controllers into your packages.
5. Also see the document, Tips for Securing a Production Expresso Environment.

For technical information about how to use security, please refer to the Expresso Developers Guide (EDG) or the Javadocs.

Here are a few areas of ehancements coming in new releases:

• The ability to export security settings so you can set all the security settings you want on your test environment, upload the file to your production environment when you're ready to go online and let 'er rip. Probably displaying the current security settings in an xml file would be most doable...
• Expresso basically ignores Servlet Security API's right now since it's hard to be container independent. You'll see integration with JAAS coming up...