RE: Security, authentication and authorisation with Struts

[Rey Francois]

We actually do more or less the same. During the login phase we retrieve the
user profile which includes the authorization information and store this in
the session context. Each action can then take some access control decision
based on this information.

However I am currently trying to use JAAS (Java Authentication and
Authorization Service) just for the authorization part. I have written a doc
on the various issues of doing so and how I'm planning to do so. I'm still
working on it but it may be useful to some of you, so I attach it. This
document mentions "eShell": this is the name of the framework we use, and it
is extending Struts.

As usual, any comments on this is welcome :)

Fr.

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 24 August 2001 15:27
To: [EMAIL PROTECTED]
Subject: RE: Security, authentication and authorisation with Struts


> I wondered what approach you guys took when implementing security,
> authentication and authorisation.  I have the common scenario 
> where the application I am creating allocates roles to certain
> types of users, allows them to login, then restricts access to
> certain pages and within the pages certain content.

I use a subclass of ActionServlet that ensures that the username
(a String) and authorization info (a bean) for this user are
saved in the session scope before any Actions are called. (They
aren't combined into one object because I need the username
for other situations when I may not require auth information.)

At the top of each Action I consult the authorization bean to see
if this user has the appropriate permissions to call this Action.
If so, I just keep going. If not, I forward to a JSP that tells
them "no". If the authorization bean doesn't exist anymore it's
because the session timed out in which case I forward to another
JSP asking them to start over. The ability to choose your view in
the Action is really, really nice.

I don't have a login procedure because there is a front-end that
they need to pass through before they get to my application
and this guarentees me a username in the HTTP headers. So I just
need to pull it out of the headers in the special ActionServlet
subclass and put it in the scope. But it would be easy enough for
a login page to do the same thing.

Devon



************************************************************************
The information in this email is confidential and is intended solely
for the addressee(s).
Access to this email by anyone else is unauthorised. If you are not
an intended recipient, you must not read, use or disseminate the
information contained in the email.
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of Capco.

http://www.capco.com
***********************************************************************

Title: Using JAAS within eShell web applications

Using JAAS within eShell web applications [Introduction] [JAAS support in eShell] [Configuration] Introduction The Java Authentication and Authorization Service (JAAS) is a standard Java API that extends the standard Java security model in order to: Provide a standard API of authenticating users while allowing different authentication methods to be plugged-in (pluggable login modules). Provide subject-based access control by extending the standard Java 2 security model: access control can be based on who is running the code in addition to which code source is running. Allow the use of a custom policy object which can retrieve user permissions from any storage. JAAS is distributed as a standard extension to the J2SE 1.3 platform, and is completely integrated into J2SE 1.4. However despite this integration, there are important issues that makes it difficult to integrate JAAS in the context of a web application. Integration Issues The issues one faces when using JAAS within a web application relate on one side to the current state of the J2EE specifications, and on the other side to the way JAAS is currently defined. At present there is no way to provide a portable solutions to these issues. Issues with the J2EE specification The issues with the current J2EE 1.2 specification is that it does not integrate JAAS. Indeed, container providers are not required to use JAAS for implementing authentication and authorization. In the case of the Servlet specification, web containers are just required to support: Basic authentication: browser asks for userid/password Form-based authentication: allow a custom screen for userid/pwd Client certificate authentication: based on PKI infrastructure Role-based access control to web resource Therefore it's only through these standard authentication and authorization mechanisms that one can benefit from container managed security (e.g. propagation of the user identity to an EJB container). The J2EE specification v1.3 goes a little further in integrating JAAS within the J2EE platform, but only in the context of the Connector Architecture (how to use JAAS in order to authenticate to an EIS resource within a connector). Container providers still still have to implement their own mechanisms for authentication and authorization. Another difficulty in integrating JAAS with the J2EE platform is that J2EE authorization is based on the role of the user. While JAAS can be used to implement role-based authorization, its scope is much larger that just role-based authorization, and can also perform user/group authorization (in fact the notion of Principal is neutral: it can represent a user, a group, role, etc.). Therefore there is a need for a standard way of defining roles, permissions, policy information, so that JAAS can be used to implement the authentication and authorization mechanism currently found in J2EE. The Java Authorization service provider Contract for Containers (JSR-115) aims at defining such standard. Although it aims at being released with the J2EE specification 1.3, it is unlikely that it will be ready in time (JSR-115 started in May 2001, no public draft available yet). Issues with JAAS itself Besides these issues related to the J2EE specifications, another difficulty in integrating JAAS with web application is due to the way JAAS defines the LoginContext class. This class provides methods to login, logout, and retrieve the subject. Because it is not Serializable, it cannot be stored in the session, or any other standard context, so that a logout can be performed at a later time. Only the Subject class is Serializable and can be stored in the session context. Why using JAAS? Facing these integration difficulties, one can wonder why should JAAS be used at present within a web application. There are a few good reasons why JAAS should still be considered for use. First JAAS is well established and integrated into the J2SE platform. It is a J2SE 1.3 Standard extension, and it is completely integrated in J2SE 1.4. Also future J2EE specifications are very likely going to integrate JAAS in a stronger manner. Using it now should help reduce the effort of migrating to the future J2EE security features. Another reason is that it provides a standard authorization mechanism enforced by the JRE environment itself. Finally is offers the flexibility to support user, groups, and roles. It also supports the use of a custom Policy object that can read user information from a custom database. However before choosing to use JAAS within a web application, one should also consider the following: Is the propagation of the identity to an EJB container necessary? If yes, the standard authentication mechanism of the web container must be used. While some container providers offers the ability to use JAAS login modules, there is no portable way to make a container use JAAS for authentication. Is the role-based container access control to web resources sufficient? If yes, the standard declarative security mechanism can be used. If not, some application-level authorization is necessary, in which case JAAS can be used. Is the portability of the solution across different web containers important? If yes, the solution should only be based the standard mechanisms defined in the J2EE specification. If not, proprietary mechanisms can be used. In respects of the above concerns, one can determine how much of JAAS can be used, and how to best integrate it within the web application. JAAS support in eShell Within eShell, only basic support for JAAS is provided. eShell does not exactly require the use of JAAS for authenticating users. This is because the current servlet specification does not require the use of JAAS authentication. On the other side, eShell does provide some support for performing JAAS-based authorization. For this to be possible, the use of a valid Subject instance is required. Getting a valid Subject instance The best way to get a valid Subject instance is, surprisingly, through the JAAS authentication mechanism. If it is possible and desirable to have the container perform a JAAS authentication, then the subject resulting from the container authentication can be used. Otherwise, if the JAAS authentication is only made necessary for creating a valid subject, a "fake" JAAS authentication based on a "fake" login module needs to be implemented. This JAAS authentication is considered "fake" because it does not serve the purpose of authenticating a user, but only to create a valid subject populated with the correct principals. For example, it is possible to have the web container perform a basic authentication (using the container's proprietary authentication mechanisms). When a user is authenticated this way, a JAAS login can trigger a JAAS login module that retrieves the principals for this user in order to construct valid subject. The login module does not try to authenticate the user, but only retrieves the set of principals for the given user (groups, roles) and create a Subject instance. In any case, eShell is not involved in getting a valid subject. The only requirement of eShell is to be able to access the Subject instance to use for access control. This is done by storing the subject in the session context (under the key "SUBJECT"). eShell support for JAAS Authorization Once a JAAS login (either "fake" or "real") is performed, eShell can use the subject stored in the session for servicing each request as the given subject, making all Actions being performed with the subject's permission defined in the JAAS policy. By default, the standard file-based policy provided with JAAS is used. Storing permissions in this way makes it cumbersome to maintain properly the access control of an application. Typically, permissions are defined in a user interface to some repository. Because the policy file tool provided with Java is not the most user-friendly, most often permissions are stored within a non-standard repository. In such cases, a non-standard policy implementation (deriving from the class javax.security.auth.Policy) must be provided. Note: In J2SE 1.3 JAAS is an optional package, which means there are two policy implementations, one for the standard Java 2 security (java.security.Policy) and one for the optional JAAS package (javax.security.auth.Policy). In the J2SE 1.4 platform, JAAS is completely integrated and both the standard Java policy and the JAAS policy have been merged. While with J2SE 1.3 it is easy to create a custom JAAS policy without touching the standard Java 2 policy, using a custom policy in J2SE 1.4 affects both JAAS and the standard security mechanism. As a result, when an application uses a custom JAAS policy implementation, migrating from J2SE 1.3 to 1.4 may require the normal Java permissions (those normally defined in standard Java 2 policy files) to be defined in the custom repository accessed by the custom JAAS policy. Configuration To be completed...