Download lecture notes

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts
no text concepts found
Transcript
JAVA AUTHENTICATION AND
AUTHORIZATION SERVICE
(JAAS)
Authentication and Authorization
 An authentication system is how you identify
yourself to the computer.
 The goal behind an authentication system is to
verify that the user is actually who they say they
are.
 There are many ways of authenticating a user.
Any combination of the following are good
examples.
 Password based authentication
 Device based authentication
 Biometric Authentication
Authentication and Authorization
 Once the system knows who the user is
through authentication, authorization is how
the system decides what the user can do.
initiate or progress a transaction, process or
activity
 Authorization is the process of granting
permission to someone or something
 in order to perform given actions.
 This is where you say that user x has permission to
access, say, a file or directory.
Authentication and Authorization
 An example: A web site that may have a number pages
protected by a username/password mechanism.
 Any user with valid credentials will be able to gain access to these pages
(authentication),
 But some of the users may be employees and have access to additional
information on other pages not accessible by ordinary users (authorization).
 Authentication and Authorization are two completely separate
acts within the administration scheme.
 A user may be authenticated but have no authorization.
 Authentication may be performed by an entity completely
separate of the area where authorization for access may reside.
 For example, I may use SecureID to authenticate a user to access routers,
 however the authorization for the router they are allowed to access resides
in the router itself where the SecureID server is external of the router.
Using JAAS Authentication
Typically involves the following steps:

Create a LoginContext

Optionally pass a CallbackHandler to the LoginContext, for
gathering or processing authentication data

Perform authentication by calling the LoginContext's login()
method

Perform privileged actions using the returned Subject
(assuming login succeeds)
Here's a minimal example:
LoginContext lc = new LoginContext ("MyExample");
try {
lc.login();
} catch (LoginException) { // Authentication failed.
} // Authentication successful, we can now continue.
// We can use the returned Subject if we like.
Subject sub = lc.getSubject();
Subject.doAs (sub, new MyPrivilegedAction());
 During initialization, the LoginContext finds the
configuration entry "MyExample" in a JAAS
configuration file (which we configured) and
 determines which LoginModules to load
 During login, the LoginContext calls each
LoginModule's login() method
Each login() method performs the authentication or enlists a
CallbackHandler
 The CallbackHandler uses one or more Callbacks
to interact with the user and gather input
 A new Subject instance is populated with
authentication details such as Principals and
credentials
JAAS configuration
Java 2 Security Model
 The ability to grant specific permissions
to a particular piece of code about
accessing specific resources on the client,
depending on the signer of the code
and/or the location from which the code was
loaded.
JAAS classes and interfaces
 Common
 Subject,
 Principal,
 credential (credential is not any specific class, but can be any object)
 Authentication
 LoginContext,
 LoginModule,
 CallbackHandler,
 Callback
 Authorization
 Policy,
 AuthPermission,
 PrivateCredentialPermission
 Most of these classes and interfaces are in the
javax.security.auth package's subpackages, with some prebuilt
implementations in the com.sun.security.auth package,
included only in J2SE 1.4.
Common Interface I
 The Subject class represents an authenticated
entity:
an end-user or administrator,
a Web service, device,
another process.
 The class contains three sets of security
information types:
Identities: In the form of one or more Principals
Public credentials: Such as name or public keys
Private credentials: Like passwords or private keys
An Explanation of Common Classes:
 A Subject may be any entity, such as a person or
service.
 Once authenticated, a Subject is populated with
associated identities, or Principals.
 A Subject may have many Principals.
For example, a person may have a name Principal ("Jane Doe")
and a Social Security Number Principal ("111-22-3333"), that
distinguish it from other Subjects.
 The getPrincipals() method retrieves the Principals
associated with a Subject.
 The static method doAs() in Subject achieves the
effect of having an action run as the subject.
 Based on whether this action is authorized, the action
completes successfully or generates an exception.
JAAS programming model
To authenticate and authorize a Subject, these steps are
performed:
 An application instantiates a LoginContext.
 The LoginContext consults a Configuration file, along the lines
of ones discussed above, to load the LoginModules configured
for that application.
 The application invokes the LoginContext's login() method.
 The login() method invokes the loaded LoginModules. Each
LoginModule attempts to authenticate the Subject. Upon
success, LoginModules associate relevant Principals and
credentials with the Subject.
 The LoginContext returns the authentication status to the
application.
 If authentication succeeds, the application retrieves the
authenticated Subject from the LoginContext.
 Upon successful authentication of a Subject, fine-grained
access controls can be placed upon that Subject by invoking
the Subject.doAs() methods. The permissions granted to that
 The following code outline illustrates how application code uses
the JAAS framework:
// Instantiate a login context
LoginContext context = new LoginContext("name",
CallbackHandler);
// Authenticate the subject
context.login();
// Retrieve the authenticated subject
Subject subject = context.getSubject();
// Enforce Access Controls
Subject.doAs(subject, action);
To implement a new login module, follow these suggested steps:
 Understand the authentication technology
 Name the LoginModule implementation
 Implement the abstract LoginModule method
 ompile the LoginModule
 Configure and test the LoginModule
 Document and package the LoginModule implementation

static doAs method in the Subject
class
When using JAAS authentication to authenticate a user, a
subject is created to represent the authenticated user.
 A subject is comprised of a set of principals,
 where each principal represents an identity for that user.
 We can grant permissions in the policy to specific principals.
 After the user has been authenticated, the application can
associate the subject with the current access control context.
 For each subsequent security-checked operation,
 The Java run time automatically determines
 whether the policy grants the required permission only to a specific
principal.
 If so, the operation is allowed only if the subject associated with
the access control context contains the designated principal.
static doAs method in the Subject
class
 Associate a subject with the current access control
context,
by calling the static doAs method from the subject class,
 passing it an authenticated subject
and
java.security.PrivilegedAction
or
java.security.PrivilegedExceptionAction.
 The doAs method associates the provided subject
with the current access control context. Then;
invokes the run method from the action.
 The run method implementation contains all the code
executed as the specified subject.
 The action executes as the specified subject.
Subject.doAs (subject, new java.security.PrivilegedAction() {
Public Object run() {
//the subject object is associated with the context of the current execution
thread
java.security.AccessController.doPrivileged ( new
java.security.PrivilegedAction() {
public Object run() {
// Subject was cut off from the current thread context
//Within the run method of a doPrivileged action block,
// the subject object is removed from the thread context
return null;
}
}); // Subject is associated with the current thread context
return null;
}
});
 Since doPrivileged blocks can be placed anywhere along the
execution path and instrumented quite often in a server
environment,
the run-time behavior of a doAs action block becomes
difficult to manage.
Class java.security.AccessController
 Documentation changed from old to new
 The AccessController class is used for access
control operations and decisions.
 More specifically the AccessController class is
used for three purposes:
to decide whether an access to a critical system
resource is to be allowed or denied based on the
security policy currently in effect
to mark code as being "privileged"
 thus affecting subsequent access determinations
to obtain a "snapshot" of the current calling context
 so access-control decisions from a different context can be
made with respect to the saved context.
Changed Methods in class
java.security.AccessController
Documentation changed from old to new
 Object doPrivileged (PrivilegedExceptionAction)
Performs the specified PrivilegedExceptionAction with
privileges enabled.
 Object doPrivileged (PrivilegedExceptionAction,
AccessControlContext)
Performs the specified PrivilegedExceptionAction with
privileges enabled and restricted by the specified
AccessControlContext.
public Class Object
 Class Object is the root of the class hierarchy.
 Every class has Object as a superclass.
 All objects, including arrays, implement the methods of
this class.
 public Object() constructor
public interface Runnable
 When an object implementing interface Runnable is used to create a
thread, starting the thread causes the object's run method to be called in
that separately executing thread.
public void run()
 The Runnable interface should be implemented by any class whose
instances are intended to be executed by a thread. The class must
define a method of no arguments called run.
 his interface is designed to provide a common protocol for objects that
wish to execute code while they are active
Common Interface II
 Principals represent Subject identities.
 They implement the java.security.Principal interface
(which predates JAAS) and java.io.Serializable.
 A Subject's most important method is getName(),
which returns an identity's string name.
 Since a Subject instance contains an array of
Principals,
it can thus have multiple names.
 Because a social security number, login ID, email
address, and so on, can all represent one user,
multiple identities prove common in the real world
Common Interface II
 The last element credential, is not a class or an
interface, but can be any object.
 Credentials can include any authentication artifact,
such as a ticket, key, or password
 specific security systems might require.
 The Subject class maintains unique Sets of private
and public credentials,
which can be retrieved with methods such as
 getPrivateCredentials() and
 getPublicCrendentials().
 These methods are more often used by security
subsystems than at the application layer.
Authentication: LoginContext
 The application layer uses LoginContext as its
primary class for authenticating Subjects.
 LoginContext also represents where JAAS's
dynamic pluggability comes into play,
because when you construct a LoginContext,
you specify a named configuration to load.
 The LoginContext typically loads the
configuration information from a text file,
 which in turn tells the LoginContext which LoginModules to
use during login.
Explanation of Authentication Classes
 The LoginContext class provides the basic methods to
authenticate Subject
 The LoginContext class also provides a way to develop
an application independent of the underlying
authentication technology using a configuration file.
 Actual authentication occurs with a call to the login()
method.
 The LoginModule interface allows you to implement
various authentication technologies that can be plugged
under an application.
 Its important methods include: login() ,commit() ,abort(),
logout()
 The CallbackHandler communicates with the user to
obtain authentication information using callbacks.
 The abstract Policy class represents the system-wide
JAAS access-control policy.
LoginContext methods
 login() :Performs login, a relatively complex
step that invokes all LoginModules specified
for this configuration.
If it succeeds, it creates an authenticated
Subject.
If it fails, it throws a LoginException.
 getSubject() :Returns the authenticated
Subject
 logout() :Logs out the authenticated Subject
and removes its Principals and credentials.
Authentication: LoginModule
 LoginModule is the interface to specific
authentication mechanisms.
 J2SE 1.4 ships with a set of ready-to-use
LoginModules,
JndiLoginModule: Verifies against a directory service
configured under JNDI (Java Naming and Directory
Interface)
Krb5LoginModule :Authenticates using Kerberos
protocols
NTLoginModule :Uses the current user's NT security
information to authenticate
LoginModule
 Modules can be configured via configuration files. A
sample entry might look like:
Login1 {
sample.SampleLoginModule required
debug=true; };
 In this case, only one module performs the
authentication.
 An attempt by Login1 to authenticate a Subject will
succeed if and only if the SampleLoginModule
succeeds.
• In that code , required represents a
LoginModuleControlFlag
LoginModuleControlFlags
 Required: The login module must succeed. Regardless
of whether it succeeds or fails, however, authentication
still proceeds down the login module list.
 Requisite: The login module must succeed. If login
succeeds, authentication continues down. However, if it
fails, control returns immediately to the application.
 Sufficient: The module doesn't have to succeed. If it
does succeed, control immediately returns to the
application.
 Optional: This login module doesn't have to succeed.
Whether it succeeds or fails, authentication still proceeds
down the login module list
Overall authentication
 Overall authentication is governed by the individual
modules and their LoginModuleControlFlag entry.
p indicates pass, f indicates fail, and * indicates don't
care entries.
Module
Criterion
Pass/Fail
SampleLoginModule Required
ppppffff
NTLoginModule
Sufficient
pfffpf
SmartCard
Requisite
*ppf*ppf
Kerberos
Optional
*pf**pf*
Overallauthentication
pppfffff
Overall authentication for a stack-based
authentication policy
What is Kerberos?
 A network authentication protocol
 Provides strong authentication
for client/server applications
 by using secret-key cryptography
 created by MIT as a solution to network security
problems
 uses strong cryptography
a client can prove its identity to a server (and vice versa) across an
insecure network connection.
 After Kerberos has been used by a client and server to
prove their identity,
 all of their communications can also be encrypted to assure the
privacy and data integrity
http://web.mit.edu/kerberos/dist/index.html
http://web.mit.edu/kerberos/kfw-2.6/kfw-2.6.1/relnotes.html
JAAS: Pluggable authentication
JAAS authorization
 Once the user executing the code has been
authenticated, the JAAS authorization component
works in conjunction with the existing Java 2
CodeSource-based access control model.
 JAAS policy extends the Java 2 policy with the
relevant Subject-based information.
 Therefore, permissions recognized and understood
in Java 2
java.io.FilePermission and java.net.SocketPermission are equally
understood and recognized by JAAS.
 Although the JAAS security policy physically resides
separately from the existing Java 2 security policy,
the two policies should be treated as one logical policy.
An extension to the Java 2 policy file syntax
grant signedBy "alias", codeBase "URL",
principal principalClass "principalName",
principal principalClass "principalName",
…… {
permission Type "name "action",
signedBy "alias";
permission Type "name "action",
signedBy "alias";
.... };
An example entry:
grant CodeBase "http://foo.com",
Signedby "foo",
Principal com.sun.security.auth.NTPrincipal "admin" {
permission java.io.FilePermission "c:/user/admin",
"read, write";
};
//Notice that the policy file entries include a Principal entry, the
basis for user-based authentication.
JAAS classes
 The JAAS classes and interfaces reside in the
following packages:
javax.security.auth
javax.security.auth.callback
javax.security.auth.login
javax.security.auth.spi
 The classes and interfaces can be categorized as:
Common classes:
Subject
,Principal ,
Credential
Authentication classes:
LoginContext , LoginModule interface , Callback, CallbackHandler
Authorization classes:
Policy , AuthPermission , PrivateCredentialPermission
Running the Sample Program with the
Login Utility
The JAAS 1.0 kit includes a sample program at
http://java.sun.com/j2se/1.4.2/docs/guide/secur
ity/jgss/tutorials/LoginSample.html#PF
To run the sample, follow all instructions at the
page above, and refer to the kit's policy files,
command lines, and other relevant material.
 The sample program first instantiates a
LoginContext.
The LoginContext consults the login configuration, which in
this example points to a single module: SampleLoginModule.
 The SampleLoginModule, loaded to perform the
authentication, prompts for a username and password.
Entering "testUser" for the username and "testPassword" for
the password, the SampleLoginModule associates a
SamplePrincipal (with "testUser" as its name) with the
current Subject, and then
 executes the SampleAction as that Subject (by calling Subject.doAs).
 The SampleAction, a privileged action, attempts to
access two System properties (java.home and
user.home), and also
attempts to access the file foo.txt in the current working
directory.
This process will succeed only for the appropriate users,
thereby accomplishing user-based authentication