Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Jetty/Tutorial/JAAS"

Line 32: Line 32:
 
</Call>
 
</Call>
 
</source>
 
</source>
warning| IMPORTANT: It is imperative that the contents of the &lt;realm-name&gt; and the &lt;Set name="name"&gt; of the JAASUserRealm instance are _exactly_ the same
+
{{warning| IMPORTANT: It is imperative that the contents of the &lt;realm-name&gt; and the &lt;Set name="name"&gt; of the JAASUserRealm instance are _exactly_ the same}}
  
 
=== Step 2 ===
 
=== Step 2 ===
Line 42: Line 42:
 
     };
 
     };
 
</source>
 
</source>
warning|IMPORTANT: It is imperative that the application name to the left of the \{ is _exactly_ the same as the &lt;Set name="LoginModuleName"&lt;
+
{{warning|IMPORTANT: It is imperative that the application name to the left of the \{ is _exactly_ the same as the &lt;Set name="LoginModuleName"&lt;}}
  
  
Line 143: Line 143:
  
 
There is no particular schema required for the database tables storing the authentication and role information. The properties userTable, userField, credentialField, userRoleTable, userRoleUserField, userRoleRoleField configure the names of the tables and the columns within them that are used to format the following queries:
 
There is no particular schema required for the database tables storing the authentication and role information. The properties userTable, userField, credentialField, userRoleTable, userRoleUserField, userRoleRoleField configure the names of the tables and the columns within them that are used to format the following queries:
<source lang="text">select <credentialField> from <userTable> where <userField> =?
+
<source lang="sql">
 +
select <credentialField> from <userTable> where <userField> =?
 
select <userRoleRoleField> from <userRoleTable> where <userRoleUserField> =?
 
select <userRoleRoleField> from <userRoleTable> where <userRoleUserField> =?
</source>Credential and role information is lazily read from the database when a previously unauthenticated user requests authentication. Note that this information is only cached for the length of the authenticated session. When the user logs out or the session expires, the information is flushed from memory.
+
</source>
 +
 
 +
Credential and role information is lazily read from the database when a previously unauthenticated user requests authentication. Note that this information is only cached for the length of the authenticated session. When the user logs out or the session expires, the information is flushed from memory.
  
 
Note that passwords can be stored in the database in plain text or encoded formats, using the [org.mortbay.jetty.security.Password|#pwd] class.
 
Note that passwords can be stored in the database in plain text or encoded formats, using the [org.mortbay.jetty.security.Password|#pwd] class.

Revision as of 12:53, 31 December 2009



Introduction

Using JAAS with jetty is very simply a matter of declaring a org.mortbay.jetty.plus.jaas.JAASUserRealm, creating a jaas login module configuration file and specifying it on the jetty run line.

Details

Let's look at an example.

Step 1

Configure a Jetty org.mortbay.jetty.plus.jaas.JAASUserRealm to match the <realm-name> in your web.xml file. For example, if the web.xml contains a realm called "xyzrealm":

<login-config>
  <auth-method>FORM</auth-method>
  <realm-name>xyzrealm</realm-name>
  <form-login-config>
    <form-login-page>/login/login</form-login-page>
    <form-error-page>/login/error</form-error-page>
  </form-login-config>
</login-config>

Then the following JAASUserRealm would be declared in a Jetty configuration file:

<Call name="addUserRealm">
  <Arg>
    <New class="org.mortbay.jetty.plus.jaas.JAASUserRealm">
      <Set name="name">xyzrealm</Set>
      <Set name="LoginModuleName">xyz</Set>
    </New>
  </Arg>
</Call>
Warning2.png


Step 2

Set up your LoginModule in a configuration file, following the syntax rules:

xyz {
       com.acme.SomeLoginModule required debug=true;
    };
Warning2.png


Step 3

Invoke jetty with the jaas configuration file you created in step 2:

> java -Djava.security.auth.login.config=mylogin.conf -jar start.jar etc/myjetty.xml

A Closer Look at the JAASUserRealm

To allow the greatest degree of flexibility in using JAAS with web applications, the JAASUserRealm supports a couple of configuration options. Note that you don't ordinarily need to set these explicitly, as Jetty has defaults which will work in 99% of cases. However, should you need to, you can configure:

  • a policy for role-based authorization (Default: org.mortbay.jetty.plus.jaas.StrictRoleCheckPolicy)
  • a CallbackHandler (Default: org.mortbay.jetty.plus.jaas.callback.DefaultCallbackHandler)
  • a list of classnames for the Principal implementation that equate to a user role (Default: org.mortbay.jetty.plus.jaas.JAASRole)

Here's an example of setting each of these (to their default values):

<New class="org.mortbay.jetty.plus.jaas.JAASUserRealm">
  <Set name="Name">xyzrealm</Set>
  <Set name="LoginModuleName">xyz</Set>
  <Set name="RoleCheckPolicy">
    <New class="org.mortbay.jetty.plus.jaas.StrictRoleCheckPolicy"/>
  </Set>
  <Set name="CallbackHandlerClass">
    org.mortbay.jetty.plus.jaas.callback.DefaultCallbackHandler
  </Set>
  <Set name="roleClassNames">
    <Array type="java.lang.String">
      <Item>org.mortbay.jetty.plus.jaas.JAASRole</Item>
    </Array>
  </Set>
</New>

RoleCheckPolicy

The RoleCheckPolicy must be an implementation of the org.mortbay.jetty.plus.jaas.RoleCheckPolicy interface and its purpose is to help answer the question "is User X in Role Y" for role-based authorization requests. The default implementation distributed with jetty is the org.mortbay.jetty.plus.jaas.StrictRoleCheckPolicy, which will assess a user as having a particular role iff that role is at the top of the stack of roles that have been temporarily pushed onto the user or if the user has no temporarily assigned roles, the role is amongst those configured for the user.

Roles can be temporarily assigned to a user programmatically by using the pushRole(String rolename) method of the org.mortbay.jetty.plus.jaas.JAASUserPrincipal class.

For the majority of webapps, the default StrictRoleCheckPolicy will be quite adequate, however you may provide your own implementation and set it on your JAASUserRealm instance.

CallbackHandler

A CallbackHandler is responsible for interfacing with the user to obtain usernames and credentials to be authenticated.

Jetty ships with the org.mortbay.jetty.plus.jaas.DefaultCallbackHandler which interfaces the information contained in the request to the Callbacks that are requested by LoginModules. You can replace this default with your own implementation if you have specific requirements not covered by the default.

Role Principal Implementation Class

When LoginModules authenticate a user, they usually also gather all of the roles that a user has and place them inside the JAAS Subject. As LoginModules are free to use their own implementation of the JAAS Principal to put into the Subject, jetty needs to know which Principals represent the user and which represent his/her roles when performing authorization checks on <security-constraint>s. The example LoginModules that ship with jetty all use the org.mortbay.jetty.plus.jaas.JAASRole class. However, if you have plugged in some other LoginModules, you must configure the classnames of their role Principal implementations.

Sample Login Modules

At the time of writing, Jetty provides four sample LoginModule implementations:

  • org.mortbay.jetty.plus.jaas.spi.JDBCLoginModule
  • org.mortbay.jetty.plus.jaas.spi.PropertyFileLoginModule
  • org.mortbay.jetty.plus.jaas.spi.DataSourceLoginModule
  • org.mortbay.jetty.plus.jaas.ldap.LdapLoginModule

We'll take a look at all of these, but first, a word about password handling in Jetty, as it applies to all LoginModules.

Passwords/Credentials

Passwords can be stored in clear text, obfuscated or checksummed. The class org.eclipse.jetty.http.security.Password should be used to generate all varieties of passwords,the output from which can be cut and pasted into property files or entered into database tables.

> java -cp lib/jetty.jar org.eclipse.jetty.http.security.Password
Usage - java org.eclipse.jetty.http.security.Password [<user>] <password>
> java -cp lib/jetty.jar org.eclipse.jetty.http.security.Password me you
you
OBF:20771x1b206z
MD5:639bae9ac6b3e1a84cebb7b403297b79
CRYPT:me/ks90E221EY

Read more on [Securing Passwords].

JDBCLoginModule

The JDBCLoginModule stores user passwords and roles in a database that are accessed via JDBC calls. You can configure the JDBC connection information, as well as the names of the table and columns storing the username and credential, and the name of the table and columns storing the roles.

Here is an example login module configuration file entry for it using an HSQLDB driver:

jdbc {
      org.mortbay.jetty.plus.jaas.spi.JDBCLoginModule required
      debug="true"
      dbUrl="jdbc:hsqldb:."
      dbUserName="sa"
      dbDriver="org.hsqldb.jdbcDriver"
      userTable="myusers"
      userField="myuser"
      credentialField="mypassword"
      userRoleTable="myuserroles"
      userRoleUserField="myuser"
      userRoleRoleField="myrole";
      };

There is no particular schema required for the database tables storing the authentication and role information. The properties userTable, userField, credentialField, userRoleTable, userRoleUserField, userRoleRoleField configure the names of the tables and the columns within them that are used to format the following queries:

SELECT <credentialField> FROM <userTable> WHERE <userField> =?
SELECT <userRoleRoleField> FROM <userRoleTable> WHERE <userRoleUserField> =?

Credential and role information is lazily read from the database when a previously unauthenticated user requests authentication. Note that this information is only cached for the length of the authenticated session. When the user logs out or the session expires, the information is flushed from memory.

Note that passwords can be stored in the database in plain text or encoded formats, using the [org.mortbay.jetty.security.Password

Additional Resources

(optional) - links, additional references

Back to the top