Authentication

Copyright © Cloud Software Group, Inc. All Rights Reserved

Authentication

A servlet-based Web application can choose from the following types of authentication, from least secure to most:

1.

Basic authentication

2.

Form-based authentication

3.

Digest authentication

4.

SSL and client certificate authentication

TIBCO Hawk HTTP Adapter relies upon declarative authentication. This requires no programming because authentication is declared with XML tags in the Web application’s deployment descriptor (HAWK_HOME/webconsole/tomcat/webapps/http/xsl/http/WEB-INF/web.xml) and implemented by the Web server or application server.

Each TIBCO Hawk HTTP Adapter can use the most appropriate method for authenticating users. This section discusses implementing declarative authentication on the Tomcat Web server as an example. Refer to your Web server’s or application server’s documentation for more information.

Basic Authentication

Basic authentication is defined by the HTTP/1.1 specification. When a client attempts to access a protected resource, the server prompts for a username and password. If the server can authenticate the username and password, access is granted to the resource; otherwise, the process repeats a specific number of times. Although basic and form-based authentication is not secure, you can use in combination with SSL for secure transport.

Users and Roles

The following code fragment from the web.xml file restricts access to the Web resources /Agent and /Alerts to members of the HawkUser role. Access to /Invoke and /MicroAgents is restricted to members of the HawkAdmin role.

The authentication mechanism is specified as basic. Passwords are transmitted with base64 encoding, which provides no encryption. A Web administrator can use digest authentication instead of basic authentication, in which a hash value of password is transmitted instead of base64 encoded format.

<web-app>

<!-- Security constraint for TIBCO Hawk Servlet

<security-constraint>

<web-resource-collection>

<web-resource-name>HawkSecure</web-resource-name>

<description>TIBCO Hawk Security</description>

<url-pattern>/Agents</url-pattern>

<url-pattern>/Alerts</url-pattern>

<http-method>POST</http-method>

<http-method>GET</http-method>

</web-resource-collection>

<auth-constraint>

<description>"HawkUser" Role, users belongs to this role are only allowed to access this resource

</description>

<role-name>HawkUser</role-name>

</auth-constraint>

</security-constraint>

<security-constraint>

<web-resource-collection>

<web-resource-name>HawkAdmin</web-resource-name>

<description>TIBCO Hawk Power User</description>

<url-pattern>/Invoke</url-pattern>

<url-pattern>/MicroAgents</url-pattern>

<http-method>POST</http-method>

<http-method>GET</http-method>

</web-resource-collection>

<auth-constraint>

<description>"HawkAdmin" Role, users belongs to this role are only allowed to access this resource

</description>

<role-name>HawkAdmin</role-name>

</auth-constraint>

</security-constraint>

<login-config>

<auth-method>BASIC</auth-method>

</login-config>

</web-app>

For the Tomcat Web server, usernames and passwords are associated with roles in $TOMCAT_HOME/conf/tomcat-users.xml. An excerpt from this configuration file is shown below.

<tomcat-users>

<user name="hawk" password="hawkhttp" roles="HawkUser"/>

<user name="hawk1" password="hawk1http" roles="HawkUser, HawkAdmin"/>

</tomcat-users>

This excerpt shows that the username hawk with the password hawkhttp is bound to one role HawkUser. The user hawk1 with the password hawk1http is bound to two roles, HawkUser and HawkAdmin.

Because of the role access privileges defined in the web.xml excerpt shown previously, the authenticated user hawk can only access the /Agent and /Alerts Web resource. The authenticated user hawk1 belongs to both roles and can access all four Web resources.

Realms

A realm is a group of usernames and passwords that identify valid users of Web applications (or set of Web applications), along with each user’s roles. Roles serve a similar purpose to groups in UNIX, as access to specific Web application resources are granted to all users belonging to a particular role. A user can belongs to more than one role.

It is often desirable to link a Web server or application server to an existing authentication database or other mechanism. Although the servlet specification describes a portable mechanism for Web applications to declare their security requirements, there is no portable API interface defining the interface between the Web server or application server and the associated user and role information.

As a result, Tomcat Web server defines a Java interface, org.apache.Catalina.Realm, that can be implemented by plug-in components to establish this connection. Three standard plug-ins are provided with Tomcat4.x, supporting connections to three different sources of authentication information:

•

MemoryRealm accesses authentication information stored in an in-memory object collection initialized from an XML document (conf/tomcat-users.xml). This is the default Tomcat Web server mechanism.

•

JDBCRealm uses a JDBC driver to access authentication information stored in a relational database.

•

JNDIRealm uses a JNDI provider to access authentication information stored in an LDAP-based directory server.

The $TOMCAT_HOME/conf/server.xml file specifies the default realm org.apache.Catalina.realm.MemoryRealm in. This file is shared by all contexts (Web applications). If the Tomcat Web server administrator selects an authentication mechanism other than MemoryRealm, the corresponding change should be made in the serverl.xml file.