Vai alla Home Page About me Courseware Federica Living Library Federica Federica Podstudio Virtual Campus 3D Le Miniguide all'orientamento Gli eBook di Federica La Corte in Rete
 
 
Il Corso Le lezioni del Corso La Cattedra
 
Materiali di approfondimento Risorse Web Il Podcast di questa lezione

Valentina Casola » 10.Java Authentication and Authorization Service (JAAS)


Introduction

The Java Authentication and Authorization Service (JAAS) was introduced as an optional package (extension) to the Java 2 SDK, Standard Edition (J2SDK), v 1.3.
JAAS was integrated into the J2SDK 1.4.

JAAS can be used for two purposes:

  • for authentication of users, to reliably and securely determine who is currently executing Java code, regardless of whether the code is running as an application, an applet, a bean, or a servlet; and
  • for authorization of users to ensure they have the access control rights (permissions) required to do the actions performed.

Introduction (cont’d)

Traditionally Java has provided codesource-based access controls (access controls based on where the code originated from and who signed the code).
It was not able to enforce access controls based on who runs the code.
JAAS provides a framework that augments the Java security architecture with such support.
It implements a Java version of the standard Pluggable Authentication Module (PAM) framework.

Introduction (cont’d)


Features

JAAS provides pre-defined modules.

It is possible to develop or import new modules.

JAAS pluggable

JAAS is pluggable; this permits applications to remain independent from underlying authentication technologies.

Any authentication technology can be plugged under an application without requiring modifications to the application itself.

The process:

  • Applications enable the authentication process by instantiating a LoginContext object, which refers to a Configuration to determine the authentication technology, or LoginModule, to be used in performing the authentication

Authorization phase

Once the user or service executing the code has been authenticated, the JAAS authorization component works in conjunction with the core Java SE access control model to protect access to sensitive resources.

Access control decisions are based both on the executing code’s CodeSource and on the user or service running the code, who is represented by a Subject object.

The Subject is updated by a LoginModule with relevant Principals and credentials if authentication succeeds.

Authentication example

SampleAcn.java contains a sample application class (SampleAcn) and another class used to handle user input (MyCallbackHandler).

SampleLoginModule.java is the class specified by the login configuration file as the class implementing the desired underlying authentication. SampleLoginModule’s user authentication consists of simply verifying that the name and password specified by the user have specific values.

SamplePrincipal.java is a sample class implementing the java.security.Principal interface. It is used by SampleLoginModule.

LoginModules


LoginModule: methods


Authentication: CallbackHandlers and Callbacks

CallbackHandlers and Callbacks enable the LoginModule to gather user credentials.

JAAS provides 7 built-in Callbacks in the javax.security.auth.callback package:

  • ChoiceCallback,
  • ConfirmationCallback,
  • LocaleCallback,
  • NameCallback,
  • PasswordCallback,
  • TextInputCallback,
  • TextOutputCallback.

Configuration files


Subjects and Principals

The JAAS framework defines the term subject to represent the source of a request. A subject may be any entity, such as a person or a service.

Once the subject is authenticated, a javax.security.auth.Subject is populated with associated identities, or Principals.

A Subject may have many Principals.

SampleAcn File

That file contains two classes:

  • The SampleAcn Class;
  • The MyCallbackHandler Class.

The main method of the SampleAcn class performs the authentication and then reports whether or not authentication succeeded. The code for authenticating the user is very simple, consisting of just two steps:

  • Instantiate a LoginContext;
  • Call the LoginContext’s login method.

1. Instantiating a LoginContext


1. Instantiating a LoginContext (cont’d)


2. Calling the LoginContext’s login()

Once we have a LoginContext lc, we can call its login method to carry out the authentication process:

  • lc.login();
  1. The LoginContext instantiates a new empty javax.security.auth.Subject object (which represents the user or service being authenticated).
  2. The LoginContext constructs the configured LoginModule (in our case SampleLoginModule) and initializes it with this new Subject and MyCallbackHandler.
  3. The LoginContext’s login method then calls methods in the SampleLoginModule to perform the login and authentication.
  4. The SampleLoginModule will utilize the MyCallbackHandler to obtain the user name and password.
  5. Then the SampleLoginModule will check that the name and password are the ones it expects
  6. If authentication is successful, the SampleLoginModule populates the Subject with a Principal representing the user.

Putting all togheter

import javax.security.auth.login.*;
. . .
LoginContext lc = new LoginContext(“Sample”, new MyCallbackHandler());

lc.login();

——————————- file sample_jaas.config —————————-

/** Login Configuration for the JAAS Sample Application **/

Sample {
sample.module.SampleLoginModule required debug=true;
};

SampleLoginModule File

SampleLoginModule.java implements the LoginModule interface. SampleLoginModule is the class specified in the configuration file as the class implementing the desired underlying authentication.

SampleLoginModule’s user authentication consists of simply verifying that the name and password specified by the user have specific values.

If authentication is successful, the SampleLogin Module populates a Subject with a SamplePrincipal representing the user.

Running the code

javac sample/SampleAcn.java
sample/module/SampleLoginModule.java
sample/principal/SamplePrincipal.java

java -Djava.security.auth.login.config=
=sample_jaas.config sample.SampleAcn

User: testUser
Pass: testPassword

Authorization phase

JAAS authorization extends the existing Java security architecture that uses a security policy to specify what access rights are granted to executing code:

BEFORE JAAS:

grant codebase “file:./SampleAcn.jar” {

permission javax.security.auth.AuthPermission “createLoginContext.Sample”;
};

Authorization phase (cont’d)

JAAS authorization augments the existing code-centric access controls with new user-centric access controls. Permissions can be granted based not just on what code is running but also on who is running it.

When an application uses JAAS authentication to authenticate the user (or other entity such as a service), a Subject is created as a result. The purpose of the Subject is to represent the authenticated user. A Subject is comprised of a set of Principals, where each Principal represents an identity for that user.

Permissions can be granted in the policy to specific Principals.

The Java runtime will automatically determine whether the policy grants the required permission only to a specific Principal and if so, the operation will be allowed only if the Subject associated with the access control context contains the designated Principal.

Example

// Java 2 codesource-based policy
grant Codebase “http://foo.com”, Signedby “foo” {
permission java.io.FilePermission “/cdrom/-”, “read”; }

// JAAS principal-based policy
grant Codebase “http://bar.com, Signedby “bar”,
Principal bar.Principal “duke” {
permission java.io.FilePermission “/cdrom/duke/-”, “read”;
}

Example (cont’d)

This example allows the code:

  • loaded by ‘bar.com’
  • signed by ‘bar’,
  • and executed by ”duke’

….to read only the files included in the ‘/cdrom/duke’ directory.

The Subject authenticated in the LoginContext must be associated to a Prinicipal whose getName method returns ‘duke’.
The policy must specify the information Codebase and SignedBy, too.

Authorization steps

To make JAAS authorization take place, the following is required:

  1. The user must be authenticated.
  2. Principal-based entries must be configured in the security policy.
  3. The Subject that is the result of authentication must be associated with the current access control context.

Principal-Based Policy File Statements

The basic format of a grant statement is:

grant , <signer(s) field> ,  <codeBase URL>

<Principal field(s)> {
permission perm_class_name “target_name” , “action”; ….
permission perm_class_name “target_name” , “action”; };

Example: sampleazn.policy

grant codebase “file:./SampleAction.jar”,
Principal sample.principal.SamplePrincipal “testUser”
{
permission java.util.PropertyPermission “java.home”,
“read”; permission java.util.PropertyPermission
“user.home”,”read”; permission java.io.FilePermission
“foo.txt”, “read”;
};

Create and associate a Subject with the current access control context

  1. After user authentication, the static doAs method from the Subject class must be called, passing it an authenticated Subject and a java.security.PrivilegedAction;
  2. The doAs method associates the provided Subject with the current Access Control Context and then invokes the run method from the action.
  3. The run method implementation contains all the code to be executed as the specified Subject. The action thus executes as the specified Subject.

The static doAsPrivileged method from the Subject class may be called instead of the doAs method. In addition to the parameters passed to doAs, doAsPrivileged requires a third parameter: an AccessControlContext.

Putting all togheter

Subject mySubject = lc.getSubject();
PrivilegedAction action = new SampleAction();
Subject.doAsPrivileged(mySubject, action, null);

The doAsPrivileged method invokes execution of the run method in the PrivilegedAction action (SampleAction) to initiate execution of the rest of the code, which is considered to be executed on behalf of the Subject mySubject.

  • Contenuti protetti da Creative Commons
  • Feed RSS
  • Condividi su FriendFeed
  • Condividi su Facebook
  • Segnala su Twitter
  • Condividi su LinkedIn
Progetto "Campus Virtuale" dell'Università degli Studi di Napoli Federico II, realizzato con il cofinanziamento dell'Unione europea. Asse V - Società dell'informazione - Obiettivo Operativo 5.1 e-Government ed e-Inclusion