alvinalexander.com | career | drupal | java | mac | mysql | perl | scala | uml | unix  

Tomcat example source code file (fs-jndi-realm.xml)

This example Tomcat source code file (fs-jndi-realm.xml) is included in the DevDaily.com "Java Source Code Warehouse" project. The intent of this project is to help you "Learn Java by Example" TM.

Java - Tomcat tags/keywords

current, current, dependencies, functionality, functionality, jndi, jndirealm, ldap, license, login, login, requested, the, the

The Tomcat fs-jndi-realm.xml source code

<?xml version="1.0"?>
<!--
  Licensed to the Apache Software Foundation (ASF) under one or more
  contributor license agreements.  See the NOTICE file distributed with
  this work for additional information regarding copyright ownership.
  The ASF licenses this file to You under the Apache License, Version 2.0
  (the "License"); you may not use this file except in compliance with
  the License.  You may obtain a copy of the License at

      http://www.apache.org/licenses/LICENSE-2.0

  Unless required by applicable law or agreed to in writing, software
  distributed under the License is distributed on an "AS IS" BASIS,
  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  See the License for the specific language governing permissions and
  limitations under the License.
-->
<!DOCTYPE document [
  <!ENTITY project SYSTEM "project.xml">
]>
<document url="fs-jndi-realm.html">

  &project;

  <properties>
    <author email="craigmcc@apache.org">Craig McClanahan
    <title>JNDIRealm
    <revision>$Id: fs-jndi-realm.xml 562814 2007-08-05 03:52:04Z markt $
  </properties>

<body>


<section name="Overview">


  <subsection name="Introduction">

    <p>The purpose of the JNDIRealm implementation is to
    provide a mechanism by which Tomcat 5 can acquire information needed
    to authenticate web application users, and define their security roles,
    from a directory server or other service accessed via JNDI APIs.  For
    integration with Catalina, this class must implement the
    <code>org.apache.catalina.Realm interface.

<p>This specification reflects a combination of functionality that is already present in the <code>org.apache.catalina.realm.JNDIRealm class, as well as requirements for enhancements that have been discussed. Where appropriate, requirements statements are marked <em>[Current] and [Requested] to distinguish them.

<p>The current status of this functional specification is <strong>PROPOSED. It has not yet been discussed and agreed to on the TOMCAT-DEV mailing list.</p> <p>The code in the current version of JNDIRealm, and the ideas expressed in this functional specification, are the results of contributions from many individuals, including (alphabetically):</p> <ul> <li>Holman, John <j.g.holman@qmw.ac.uk> <li>Lockhart, Ellen <elockhart@home.com> <li>McClanahan, Craig <craigmcc@apache.org> </ul> </subsection> <subsection name="External Specifications"> <p>The implementation of this functionality depends on the following external specifications:</p> <ul> <li>Java Naming and Directory Interface</a> (version 1.2.1 or later) </ul> </subsection> <subsection name="Implementation Requirements"> <p>The implementation of this functionality shall conform to the following requirements:</p> <ul> <li>Be realized in one or more implementation classes. <li>Implement the org.apache.catalina.Realm interface. [Current]</li> <li>Implement the org.apache.catalina.Lifecycle interface. [Current]</li> <li>Subclass the org.apache.catalina.realm.RealmBase base class.</li> <li>Live in the org.apache.catalina.realm package. [Current]</li> <li>Support a configurable debugging detail level. [Current] <li>Log debugging and operational messages (suitably internationalized) via the <code>getContainer().log() method. [Current] </ul> </subsection> </section> <section name="Dependencies"> <subsection name="Environmental Dependencies"> <p>The following environmental dependencies must be met in order for JNDIRealm to operate correctly:</p> <ul> <li>The desire to utilize JNDIRealm must be registered in <code>$CATALINA_HOME/conf/server.xml, in a <code><Realm> element that is nested inside a corresponding <code><Engine>, <Host>, or <code><Context> element. <li>If the Administrator Login operational mode is selected, the configured administrator username and password must be configured in the corresponding directory server.</li> <li>If the Username Login operational mode is selected, the corresponding directory server must be configured to accept logins with the username and password that will be passed to <code>JNDIRealm by the appropriate Authenticator. </li> </ul> </subsection> <subsection name="Container Dependencies"> <p>Correct operation of JNDIRealm depends on the following specific features of the surrounding container:</p> <ul> <li>Interactions with JNDIRealm will be initiated by the appropriate <code>Authenticator implementation, based on the login method that is selected.</li> <li>JNDIRealm must have the JNDI API classes available to it. For a JDK 1.2 container, that means <code>jndi.jar and the appropriate implementation (such as <code>ldap.jar) must be placed in the <code>server/lib directory. </ul> </subsection> </section> <section name="Functionality"> <subsection name="Operational Modes"> <p>The completed JNDIRealm must support two major operational modes in order to support all of the required use cases. For the purposes of this document, the modes are called <em>administrator login and <em>Username Login. They are described further in the following paragraphs.</p> <p>For Administrator Login mode, JNDIRealm will be configured to establish one or more connections (using a connection pool) to an appropriate directory server, using JNDI APIs, under a "system administrator" username and password. This is similar to the approach normally used to configure <code>JDBCRealm to access authentication and access control information in a database. It is assumed that the system administrator username and password that are configured provide sufficient privileges within the directory server to read (but not modify) the username, password, and assigned roles for each valid user of the web application associated with this <code>Realm. The password can be stored in cleartext, or in one of the digested modes supported by the <code>org.apache.catalina.realm.RealmBase base class.

<p>For Username Login mode, JNDIRealm does not normally remain connected to the directory server. Instead, whenever a user is to be authenticated, a connection to the directory server (using the username and password received from the authenticator) is attempted. If this connection is successful, the user is assumed to be successfully authenticated. This connection is then utilized to read the corresponding security roles associated with this user, and the connection is then broken.</p> <p>NOTE - Username Login mode cannot be used if you have selected login method <code>DIGEST in your web application deployment descriptor (<code>web.xml) file. This restriction exists because the cleartext password is never available to the container, so it is not possible to bind to the directory server using the user's username and password.</p> <p>Because these operational modes work so differently, the functionality for each mode will be described separately. Whether or not both modes are actually supported by a single class (versus a class per mode) is an implementation detail left to the designer.</p> <p>NOTE - The current implementation only implements part of the <em>Administrator Lookup mode requirements. It does not support the <em>Username Lookup mode at all, at this point.

</subsection> <subsection name="Administrator Login Mode Functionality"> <h3>Configurable Properties <p>The implementation shall support the following properties that can be configured with JavaBeans property setters:</p> <ul> <li>connectionURL - URL of the directory server we will be contacting.</li> <li>contextFactory - Fully qualified class name of the JNDI context factory used to retrieve our InitialContext. [com.sun.jndi.ldap.LdapCtxFactory]</li> <li>Additional configuration properties required to establish the appropriate connection. [Requested]</li> <li>Connection pool configuration properties. [Requested] <li>Configuration properties defining how a particular user is authenticated. The following capabilities should be supported: <ul> <li>Substitute the specified username into a string. [Requested] <li>Retrieve the distinguished name (DN) of an authorized user via an LDAP search string with a replacement placeholder for the username, and comparison of the password to a configurable attribute retrieved from the search result. [Current]</li> </ul> <li>Configuration properties defining how the roles associated with a particular authenticated user can be retrieved. The following approaches should be supported: <ul> <li>Retrieve a specified attribute (possibly multi-valued) from an LDAP search expression, with a replacement placeholder for the DN of the user. [Current]</li> <li>Retrieve a set of role names that are defined implicitly (by selecting principals that match a search pattern) rather than explicitly (by finding a particular attribute value). [Requested]</li> </ul> </ul> <h3>Lifecycle Functionality <p>The following processing must be performed when the start() method is called:</p> <ul> <li>Establish a connection to the configured directory server, using the configured system administrator username and password. [Current]</li> <li>Configure and establish a connection pool of connections to the directory server. [Requested]</li> </ul> <p>The following processing must be performed when the stop() method is called:</p> <ul> <li>Close any opened connections to the directory server. </ul> <h3>Method authenticate() Functionality <p>When authenticate() is called, the following processing is required:</p> <ul> <li>Acquire the one and only connection [Current] or acquire a connection from the connection pool [Requested].</li> <li>Authenticate the user by retrieving the user's Distinguished Name, based on the specified username and password.</li> <li>If the user was not authenticated, release the allocated connection and return <code>null. <li>Acquire a List of the security roles assigned to the authenticated user.</li> <li>Construct a new instance of class <code>org.apache.catalina.realm.GenericPrincipal, passing as constructor arguments: this realm instance, the authenticated username, and a <code>List of the security roles associated with this user.</li> <li>WARNING - Do not attempt to cache and reuse previous <code>GenericPrincipal objects for a particular user, because the information in the directory server might have changed since the last time this user was authenticated.</li> <li>Return the newly constructed GenericPrincipal. </ul> <h3>Method hasRole() Functionality <p>When hasRole() is called, the following processing is required:</p> <ul> <li>The principal that is passed as an argument SHOULD be one that we returned (instanceof class <code>org.apache.catalina.realm.GenericPrincipal, with a <code>realm property that is equal to our instance. <li>If the passed principal meets these criteria, check the specified role against the list returned by <code>getRoles(), and return true if the specified role is included; otherwise, return <code>false. <li>If the passed principal does not meet these criteria, return <code>false. </ul> </subsection> <subsection name="Username Login Mode Functionality"> <h3>Configurable Properties <p>The implementation shall support the following properties that can be configured with JavaBeans property setters:</p> <ul> <li>connectionURL - URL of the directory server we will be contacting.</li> <li>contextFactory - Fully qualified class name of the JNDI context factory used to retrieve our InitialContext. [com.sun.jndi.ldap.LdapCtxFactory]</li> <li>Additional configuration properties required to establish the appropriate connection. [Requested]</li> <li>Connection pool configuration properties. [Requested] <li>Configuration properties defining if and how a user might be looked up before binding to the directory server. The following approaches should be supported: <ul> <li>No previous lookup is required - username specified by the user is the same as that used to authenticate to the directory server.</li> <li>Substitute the specified username into a string. <li>Search the directory server based on configured criteria to retrieve the distinguished name of the user, then attempt to bind with that distinguished name.</li> </ul> <li>Configuration properties defining how the roles associated with a particular authenticated user can be retrieved. The following approaches should be supported: <ul> <li>Retrieve a specified attribute (possibly multi-valued) from an LDAP search expression, with a replacement placeholder for the DN of the user. [Current]</li> </ul> </ul> <h3>Lifecycle Functionality <p>The following processing must be performed when the start() method is called:</p> <ul> <li>None required. </ul> <p>The following processing must be performed when the stop() method is called:</p> <ul> <li>None required. </ul> <h3>Method authenticate() Functionality <p>When authenticate() is called, the following processing is required:</p> <ul> <li>Attempt to bind to the directory server, using the username and password provided by the user.</li> <li>If the user was not authenticated, release the allocated connection and return <code>null. <li>Acquire a List of the security roles assigned to the authenticated user.</li> <li>Construct a new instance of class <code>org.apache.catalina.realm.GenericPrincipal, passing as constructor arguments: this realm instance, the authenticated username, and a <code>List of the security roles associated with this user.</li> <li>WARNING - Do not attempt to cache and reuse previous <code>GenericPrincipal objects for a particular user, because the information in the directory server might have changed since the last time this user was authenticated.</li> <li>Return the newly constructed GenericPrincipal. </ul> <h3>Method hasRole() Functionality <p>When hasRole() is called, the following processing is required:</p> <ul> <li>The principal that is passed as an argument SHOULD be one that we returned (instanceof class <code>org.apache.catalina.realm.GenericPrincipal, with a <code>realm property that is equal to our instance. <li>If the passed principal meets these criteria, check the specified role against the list returned by <code>getRoles(), and return true if the specified role is included; otherwise, return <code>false. <li>If the passed principal does not meet these criteria, return <code>false. </ul> </subsection> </section> <section name="Testable Assertions"> <p>In addition the the assertions implied by the functionality requirements listed above, the following additional assertions shall be tested to validate the behavior of <code>JNDIRealm:

<ul> </ul> </section> </body> </document>
... this post is sponsored by my books ...

#1 New Release!

FP Best Seller

 

new blog posts

 

Copyright 1998-2024 Alvin Alexander, alvinalexander.com
All Rights Reserved.

A percentage of advertising revenue from
pages under the /java/jwarehouse URI on this website is
paid back to open source projects.