Securing User Interfaces

In the previous posts I showed how to check authorization in a Java method. Now we'll consider how to secure part of the user interface.

The Flexess client integration tag library is provided as a set of tags for accessing the basic authorization operations of the com.jresearchsoft.uam.client.IAuthorizationManager.

The main tag is called check. This tag simply invokes the check method of the IAuthorizationManager. Below is an example of how it's used:

<flexess-client:check operation="list" 
            className="${sumRequestConst.USER_CLASS_NAME}"> 
    <jsp:attribute name="TRUE"> 
       <jsp:forward page="user/list.htm" /> 
    </jsp:attribute>
    <jsp:attribute name="FALSE">
         <jsp:forward page="editUser.htm">
             <jsp:param name="user.id" 
                        value="${sessionScope.FORM_AUTHENTICATION.userName}"/>
         </jsp:forward>
    </jsp:attribute>
</flexess-client:check>

If the check operation requires some attributes, they can be provided in two ways - as a java.util.Map in the attributeMap:

<flexess-client:check operation="list" 
                      className="${sumRequestConst.USER_CLASS_NAME}" 
                      attributeMap="${someScope.someName}"> 

... or with dynamic attributes:

<flexess-client:check operation="list" className="${sumRequestConst.USER_CLASS_NAME}" 
                      someAttributeName1="someAttributeValue1" 
                      someAttributeName2="someAttributeValue2">

Flexess Versus Spring Security

There is one question that I hear every day:  What are the reasons for choosing your product over Spring Security? In this post I will discuss the differences between Flexess and Spring Security (aka acegi).

Spring Security is a great framework for securing applications. It covers all the significant aspects of security like authetication, authorization, channel security, etc.  It is a set of Java libraries that operate on the level of method invocation and web requests and as a result require binding secuirty aspects to the code. Such an approach is oftentimes not very convenient because any modification of the secuirty rules require code changes.  Flexess is positioned on the other level of abstraction. Flexess decouples the secuirty rules from program code by providing a definition of the application's security model. The protected objects, operations, permissions and roles are created almost entirely independently from the code. This approach allows to support access management rules not only created by developers but also by other non-technical people (for example, business analysts or even customers).

Administration of access management rules in Spring Security is done on the level of configuration files, database tables or LDAP records. Flexess is not only a security framework but also contains a web-based administrative application, which allows creating new roles and managing user-role assignments.

One of the most powerful features of Flexess is instance-level security. The typical example is that a user is only allowed to edit his/her own profile. In Spring Security such rule requires implementing the custom AccessDecisionVoter. In Flexess this rule is declarative and is defined while creating the security model.

I must admit that in support of authentication methods, Flexess is far behind Spring Secuirty. Spring Secuirty supports BASIC, Digest, Form authentication, authentication based on JAAS, and many other methods. The examples that come with Flexess show how to use Flexess authorization together with Spring Security for these purposes.

The Flexess Development Cycle

I think it's still not clear if Flexess is a framework, a tool or a library. This entry will give an overview Flexess's structure.

The work of a developer begins with the Flexess Security Modeler. This is an Eclipse-based tool that allows creating and editing an application's security model. After creation, the model is serialized as an XML file and deployed to the Flexess Server.

After the model is deployed, it must be associated with a user management system. Flexess Administration is a J2EE application with a web client for configuring the model.  In Flexess administration we set the parameters of the connection to the LDAP server where the users who will access the application are stored.

Flexess Administration is also used as the main administration client and provides the following functions:

• Creating roles based on role templates;


• Assigning(Revoking) user to(from) roles.

The final step in the process is securing the business application. We have a library (a jar file) Flexess client. This library is deployed as part of the business application and performs the actual authorization. It loads the roles for a particular user from the Flexess Engine and checks if the user is authorized to perform the relevant operation.

To enable authorization, the code in business application must include something like this:

public void saveOrder(Order order) throws AccessControlException, UamClientException {
    getAuthorizationManager().check(order, "update" );
    dao.saveOrder(order);
}


 

The Algorithm of Evaluation

All the roles in the previous postings have only one permission, however a user is allowed to have several roles, and each role is allowed to have several permissions. So how is access granting evaluated? Currently the following rules apply in Flexess:

• If a permission has no constraint, it evaluates to true. If the permission has a constraint, then the result is the evaluation of the constraint.


• If at least one permission from the role evaluates to false, then role evaluates to false.


• If a least one role evaluates to true, then access is granted.

The following figure depicts the algorithm of evaluation:

 

In future releases we plan to have the algorithm of permission evaluation completely configurable.

User-defined Attributes

In the previous posts we discussed how to create complex constraints and compared the attributes of protected objects with them. However, this does not help solve cases like "users are only allowed to view requests, which they themselves created."  Here we need to compare an attribute of the request with an attribute of the user attempting to perform the operation. The model for such a constraint is shown in the picture below:

 

Here we have a protected object Loan with an attribute createdBy. This attribute holds the identifier of the user who applied for the Loan. The ViewPermission has an attribute userId with a stereotype user. This means that the value for this attribute is taken from the attributes of the user accessing the object. If the createdBy attribute of the protected object and  the userId of the permission are equal, then access is granted.  

It is possible to define a constraint using any user attribute stored in the user management system and the attribute can be referred to by name. If for some reason it is not desirable to refer to the attribute by name, then mapping between the attributes in Flexess and those in the user management system can be defined.

 

Using LDAP with Flexess (Part 2)

In this article we will discuss setuping up and managing a connection between Flexess and an LDAP.

To creating a new LDAP UMI Connection in Flexess Administrator you need to to the following: 

1. Click the Server Management tab and then create the UMI connection.
2. Select jresearchsoft.flexess.ldap from the dropdown list. 

   You will see the following LDAP connection form:

   .

3. Fill in the name of created connection with an optional description (1) and the name of the host and port where the LDAP Server is run (2). If you are not sure about the Base DN field, leave it empty.
4. Set the Use anonymous connection (3) to "yes" or enter the full Distinguish Name (DN) and password (4) of the user whose account is to be used to connect to the LDAP server. 
5. The object class field (5) defines the object class of user records in LDAP. By default it is a person. The connector treats all objects with a given class as user records. 
6. The user id attribute (6) is the LDAP attribute that will be used as the user login name in Flexess. 
7. The search scope (7) field defines the scope of the search. The search always starts from the Base DN level and may be limited by only one level or set to perform searches in the whole sub-tree. 
8. The Attribute (8) and Mapping (9) settings are optional and are used for connection tuning. See Managing User Profile Attributes and Using Attribute Mapping for more information.
9. Click on the select button after filling out the form.

The LDAP UMI connector saves the settings and tries to establish a connection. The connection and its status are displayed on the UMI Connections page (Server Management > UMI Connections).

The following table explains the possible statuses and extended information that they provide:

Status	Extended information	Possible reason	Action
ERROR	Cannot connect to ldap://localhost:389	The host name or port is not correct	Check the host and port settings
		The LDAP server is not running	Check if the LDAP server is running and accessible from the Flexess computer.
ERROR	Cannot connect to ldap://fire.jresearch.org:10389 with base name o=r. The server reports the following base DN: dc=example,dc=com	Incorrect Base DN.	Use one base DN from provided list.
ERROR	Cannot connect to ldap://server.jresearch.org:10389. Check if the server accepts the connections from your IP	The LDAP server denied the connection from your network. The LDAP server logs may contain more information.	Contact the LDAP server administrator.
ERROR	Cannot connect to ldap://server.jresearch.org:10389. Wrong login or password: [LDAP: error code 48 - binds with a dn require a password]	LDAP Server does not allow the use of empty passwords to connect	Assign a password.
ERROR	Cannot connect to ldap://server.jresearch.org:10389. Wrong login or password: [LDAP: error code 32 - No Such Object]	There are not any users with the given user DN	Check the user's distinguish name.
ERROR	Cannot connect to ldap://server.jresearch.org:10389. Wrong login or password: [LDAP: error code 49 - Invalid Credentials]	Incorrect password	Check the user password
WARNING	Server does not support listing	LDAP Server does not support PRC 2696 or VLV	If the server supports another paging mechanism, you can submit a request for its support in future installations.
		Selected user does not have rights to check paging controls	Check the user rights.

 To edit the configured UMI LDAP Connection you should select the name of the connection on the UMI Connections page.

Using LDAP with Flexess (Part 1)

As you know from the previous post, Flexess can be optioinally integrated with any User Management system to authenticate users and retrieve user attributes to check constraints. In this post we will review the general features of the Flexess LDAP connector.

LDAP user management for Flexess enables the use of user profiles and their authentication against a general LDAP. For general information about UMI connectors, managing UMI connections and setting up applications, see the User Management Interface section in the Flexess Development Guide.

The implemented LDAP UMI Connector provides the following functionality

• Access to user profiles stored on the LDAP server.
• Parameterized searching in LDAP.
• User authentication against LDAP.
• User paging on the LDAP side by RFC 2696 or Virtual List Views.
• Auto-selection of the paging mechanism.
• Flexible user attribute retrieving (by object class with exclude and include lists).
• Attribute name mapping from LDAP to Flexess namespace.
• Setup helpers - suffix retrieval, showing server capabilities, attribute name retrieval. 

Prerequisites.

Before setting up the LDAP UMI connection you need to collect all the information listed in following table:

Field	Description	Example
Host name	The name or IP of the host where LDAP is located	localhost
Port number	The port number for LDAP	389
User DN and password to access LDAP server	LDAP UMI connector uses the given account to connect and retrieve information. As an alternative you can use anonymous access	cn=Directory Manager
Base DN (optional)	Path inside LDAP to the user subtree. The must contain at least one of the configured suffixes. If you omit these settings on the first step, the connection is not created successfully but the status message contains all accessible suffixes.	dc=example,dc=com
User object class	To retrieve users from LDAP the UMI LDAP connector should have criteria set up in order to select the right records. This can be done using the record object class. Usually user records have at least a "person" object class.	person, inetOrgPerson

User Management Systems

By "user management system" I mean the system that stores information about users. A user has an identifier along with a number of attributes, such as first name, last name, date of birth and so forth. Examples of such storage systems could be a directory server or a relational database.

User management systems store all user attributes, but Flexess only requires the user's identifier and the associates this identifier with several roles.

Flexess is designed to be independent of user management systems. The current release allows to work with an LDAP server or with our own implementation of a user management system based on a relational database. Our database application is called Simple User Management system (SUM). SUM provides basic functionality for user administration and enables you to create, search, update and delete users. SUM is always deployed as a part of Flexess.

Role Templates, Roles and Users

In this section I will explain the concepts of roles, role templates and also discuss how roles are associated with users.

Suppose we have three type of clients in our bank: student, standard and VIP.  Each manager only works with clients of a certain type. In our security model this means that we have a role template Manager, which is associated with ClientPermission. ClientPermission has one attribute clientType, which represents the type of the client.

 

Users are associated with roles, which are created from role templates. To create a role from a role template, we give values to all the attributes of the associated permissions. Let's create three roles from the Manager role template: StudentManager, StandardManager and VIPManager:

These roles can now be associated with users. For example, Jane is VIP manager:

Attributes of role templates can be used in constraints. In our model we compare the attribute of the protected object Loan with the attribute of the ClientPermission. If the values of the attributes are equal, then access is granted:

Creating Complex Constraints

Real examples of authorization rules are complex. Restricting access to an operation is typically not enough. The previous example, where a manager can approve a loan may require additional constraints like "if the amount of the loan is greater than 1000$, then it can only be approved by a senior manager".  Another typical example is that clients can only see requests for the loans that they themselves submitted.

How can we cope with this task? Easily. We create a rule that contains a logical expression like "loan.amount<1000" and attach it to the permission. The model with constraints is shown in the picture below:

 

We put the constraint on the ApprovePermission so that now users with the role Manager can only approve loans with an amount less than 1000.  However the users with the role Senior Manager don't have any restrictions on the Approve operation and so they can approve any loan.

Constraints on permissions can also have attributes belonging to a specific user. For example, an operation could be restricted for users under the age of 18. In this case, users would have attribute age and the constraint would compare that attribute with the constant. But we'll talk about users later in the next section

Designing a Security Model

Let's consider a simple example. A client of a bank can request a loan and a manager of that bank can approve loans. We can protect the object Loan from unauthorized access by restricting access to the operations Request and Approve. These operations have relationships with permissions that limit access.

 

The client and the manager of the bank are called role templates in Flexess (I will explain why we call them role templates and not roles later). Role templates aggregate permissions. In the picture above, a Manager is allowed to perform the Approve operation because they have the ApprovePermission, which is connected to the Approve operation. A Client is not allowed to perform Approve operations because it has no permissions that are connected to the Approve operation.

Protected objects, operations, permissions and role templates are the basic concepts of Flexess. In the next post I will discuss how to restrict access based on object attributes.

The Birth of Flexess

One day I realized that if I wanted to have a security framework, I needed to implement it myself. The problem that bothered me most of all was authorization. I was pretty happy with the cryptography provided by standard Java and various authentication methods provided by acegi, but I was basically missing two things:

• The ability to grant access to objects based on the values of their attributes; and


• Being able to easily cofigure the logic of access management by having the possibility to change access rules through some tool with a user interface.

I was honestly surprised when I couldn't find a solution on the market that offered those things.  Well, I'm not talking about IBM Tivoli Identity Manager or other monsters... they were definitely out of consideration because of their price.  

Another painful problem is the security model. The most popular access control paradigm is role-based access control, which defines concepts like roles, users and permissions. But what entity do we actually protect? Do we protect an object? Or a method of an object? What is permission? Does it only have an identifier or is it an object with a complex structure? Those were the questions that I felt needed answering.

Flexess is our attempt to answer those questions. Our project didn't appear in one day but it was a very long and hard process. First we created a conceptual model of our framework that we ended up throwing away after some time Afterwards, when we succeeded in building a model that all of us liked, we started implementation. As you can guess, several of our first attempts went in the garbage can but now we finally have a result that we're all happy with. Even if you decide not to use our solution, I hope that you will at least find some useful ideas here.   

Stay with us Next post is coming in a week ...