Download Java Authentication and Authorization System

Java Authentication and Authorization
System
Carlo U. Nicola, SGI FHNW
With extracts from publications of :
Sun developers' center documentation;
Klaus Ostermann, TH-Darmstadt.
Topics
→
→
→
→
→
→
JAAS core classes
JAAS PAM: Plug-ins for authentication
The different authentication’s phases
JAAS authorization
CodeSource and ProtectionDomain classes
Java security model: Pro and contra
AS HS ’10 2
Security Model: Java
Java PEP:
SecurityManager, AccessController, AccessControlContext,
using Permission, ProtectionDomain management,...
Java PAP → File: java.security
Java PIP → File: java.policy
grant codeBase …{
permission.java.security.AllPermissions;
}
Java PDP:
if (sm != null){
context = sm.getSecurityContext();
Filepermission p = new Fileprmission(filename, “read”);
sm.checkPermission(p,context);
}
AS HS ’10 3
JAAS
Java Authentication and Authorization Service is
modeled upon the Unix PAM technique, i.e. the use of
different pluggable authenticators for passwords, smart
cards, biometric devices, etc.
– Authenticators may be required, requisite (stop on
failure), sufficient (but not required), or optional
– Adds user-centric (vs. code-centric) control:
permissions granted to Principal (not just
CodeSource), implemented through a modified
SecurityManager
AS HS ’10 4
JAAS core classes
Common Classes
→ Subject
→ Principal
→ Credential (actually, any Object)
Authentication Classes and Interfaces
→ LoginContext
→ LoginModule
→ CallbackHandler and Callback
Authorization Classes
→ Policy
→ AuthPermission
→ PrivateCredentialPermission
AS HS ’10 5
Authentication versus authorization
Authentication is the process of
verifying the users’ identity.
Typically this entails obtaining a
credential from the user (password,
certificate, physical token, biometric data).
Authorization is the process of verifying
whether an authenticated user has access
to protected resources.
AS HS ’10 6
The Subject
The Subject is a container for:
•
•
•
Associated principals
Public credentials
(e.g.:public keys)
Private credentials
(e.g.: passwords,
private keys).
The Subject can be a person,
a corporation, an application,
etc.
AS HS ’10 7
The Principal
public interface Principal {
...
public String getName();
}
A Principal identifies a subject.
A single subject may have many Principals that serve to identify it. For
example an employee may have many principals associated to it:
• A user’s name e.g., “Galileo Galilei"
• An employee id e.g., "E 12-XB-1986"
• An AHV number …
AS HS ’10 8
Obtaining a specific Principal
// List the principals
Set userPrinSet = subject.getPrincipals(UserPrincipalExample.class);
Iterator userPrinItr = userPrinSet.iterator();
System.out.println("Found the following UserPrincipalsExample:");
while (userPrinItr.hasNext()) {
Principal p = (Principal) userPrinItr.next();
System.out.println("\t" + p.toString());
}
Applications (and app. servers) typically adopt a convention stating that
the Set of Principals on a Subject can only contain one instance of a
particular Principal class.
AS HS ’10 9
JAAS: PAM (Pluggable Authentication Module)
pluggable
stack
plug-ins
An application using JAAS for authentication
can remain independent of the underlying
authentication technology.
AS HS ’10 10
Authentication
1. The application creates a LoginContext and calls login()
2. The LoginContext refers to the LoginConfiguration to set
up the appropriate LoginModules
3. The LoginContext delegates the authentication to the
LoginModules
4. The LoginModules use the CallbackHandler to communicate
with the application
AS HS ’10 11
JAAS: Authentication with LoginModule
AS HS ’10 12
Login example (1)
// Use the "Example" entry in the login configuration file
// to authenticate users.
LoginContext loginContext = null;
try {
loginContext = new LoginContext("Example",
new ExampleCallbackHandler());
loginContext.login();
} catch (AccountExpiredException e) {
...
} catch (CredentialExpiredException e) {
...
} catch (FailedLoginException e) {
...
} catch (LoginException e) {
/** Login Configuration File for JAAS Sample App **/
...
Example
} catch (Exception
e) {
x.y.z.SimpleLoginModule required debug=true;
...
};
}
AS HS ’10 13
Login example (2)
Once the login succeeds we can get the subject from the LoginContext
and get its authenticated Principals.
// List the Principals the authenticated user has
Subject subject = loginContext.getSubject();
Iterator principalItr = subject.getPrincipals().iterator();
System.out.println("The authenticated user has the " +
"following Principals:");
while (principalItr.hasNext()) {
Principal p = (Principal) principalItr.next();
System.out.println("\t" + p.toString());
}
AS HS ’10 14
Creating a LoginContext (1)
public class LoginContext {
public LoginContext(String
public LoginContext(String
public LoginContext(String
public LoginContext(String
name)
name,
name,
name,
{ ... }
Subject subject) {...}
CallbackHandler handler) { ... }
Subject subject,
CallbackHandler handler) { ... }
...
}
The name parameter is used to retrieve the appropriate login
Configuration :
→ If a login Configuration with the specified name is not found,
a default entry with the name other is used. If there is no
Configuration with the name other, a LoginException
is thrown;
→ If no subject is specified, LoginContext creates an empty
Subject.
AS HS ’10 15
Creating a LoginContext (2)
The class constructors without CallbackHandler as parameter
either:
→ Rely on the default CallbackHandler specified in the
java.security file under the property named
auth.login.defaultCallbackHandler
or:
→ Rely on the LoginModules to have other means of
obtaining the information, forgetting the CallbackHandler
AS HS ’10 16
The CallbackHandler
CallbackHandler is an interface with one method to implement:
void handle(Callback[] callbacks) throws java.io.IOException,
UnsupportedCallbackException;
Typical structure of an implementation:
public void handle(Callback[] callbacks) throws IOException,
UnsupportedCallbackException {
for (int i = 0; i < callbacks.length; i++) {
if (callbacks[i] instanceof TextOutputCallback) {
// display a message according to a specified type . . .
} else if (callbacks[i] instanceof NameCallback) {
// prompt the user for a username . . .
} else if (callbacks[i] instanceof PasswordCallback) {
// prompt the user for a password . . . }
else {
throw new UnsupportedCallbackException (callbacks[i],
"Unrecognized Callback");
}}}
AS HS ’10 17
The login()
Authentication occurs with a call to the login() method:
→ The login() method invokes all the configured LoginModules
to perform the authentication
→ When the authentication succeeds, the Subject can be retrieved
using the getSubject() method
→ The logout() method logs out the Subject and removes its
authenticated Principals
public class LoginContext {
...
public void login() throws LoginException { }
public void logout() throws LoginException { }
public Subject getSubject() { }
}
AS HS ’10 18
Chaining of LoginModules
Required
→ The LoginModule is required to succeed. If it succeeds or fails,
authentication still continues to proceed down the LoginModule
list.
Requisite
→ The LoginModule is required to succeed. If it succeeds,
authentication continues down the LoginModule list. If it fails,
control immediately returns to the application
Sufficient
→ The LoginModule is not required to succeed. If it does succeed,
control immediately returns to the application. If it fails → list.
Optional
→ The LoginModule is not required to succeed. If it succeeds or
fails, authentication still continues to proceed down the
LoginModule list.
AS HS ’10 19
Chaining of LoginModules: example
Login2 {
sample.SampleLoginModule required;
com.sun.security.auth.module.NTLoginModule sufficient;
com.foo.SmartCard requisite debug=true;
com.foo.Kerberos optional debug=true;
};
AS HS ’10 20
JAAS : Authorization
AS HS ’10 21
CodeSource authorization
Before the integration of JAAS with Java security, authorization
decisions were strictly based on the CodeSource:
→ A Trusted Library may be given access to sensitive resources
while an Applet or another Library may have that access
restricted.
AS HS ’10 22
CodeSource and Principal authorization
With the integration of JAAS and J2SE Security, authorization decisions
can be made based on the CodeSource and the Principal:
→ A library may not have access privileges to resources when
running without a user context or when being executed by user
Bart, but when user Andy executes the library those
permissions may be granted.
AS HS ’10 23
CodeSource and ProtectionDomain
The CodeSource of a piece of Java
code is the URL location that the
code was loaded from and the
certificates that we used to sign the
code
The ProtectionDomain is a holder
for the CodeSource and a Principal
Each class is assigned a
ProtectionDomain upon being
loaded. The Principal is null when
the class is first loaded.
AS HS ’10 24
Granting access to resources
When making access decisions, the security system looks at every
ProtectionDomain involved in the call. Access is granted only if
every ProtectionDomain in the Context can have access.
Principle of least privilege: A less privileged PD can not gain privilege
by calling a more privileged PD. And a more privileged PD must lose
privilege when calling a less privileged PD.
Each class has its
own protection
domain (PD)
AS HS ’10 25
The Policy class
The mapping between PDs and associated Permissions is
stored by the Policy.
AS HS ’10 26
The AccessController class
In the program you may verify that the current context has a permission by
creating a new instance of the permission in question and calling
AccessController.checkPermission(p);
MyPermission p = new MyPermission(fileName, "display");
AccessController.checkPermission(p);
AS HS ’10 27
The AccessController
The AccessController embodies the PEP (Policy Enforcement Point).
It obtains the current AccessControlContext, which has an array of
PDs and then for each PD checks whether the PD has the requested
permission ( ∩ PDi ) .
AS HS ’10 28
Security policy
grant [CodeBase <URL>,] [Signedby <signers>,]
[Principal <Principal_Class> <Principal_Name>] {
Permission <Permission_Class> [<Target_Name>]
[, <Permission_Actions>]
[, signedBy <Signer_Name>];
};
The default implementation of Policy accepts text based configuration in
the above format:
→ Each grant entry is composed of an optional CodeSource,
Signers, Principals, and a list of Permissions
→ Default security policy is <JRE_HOME>/lib/security/java.policy
→ Can provide supplemental policy file location via:
-Djava.security.policy=<file> JVM parameter
→ Can override the default policy file with:
-Djava.security.policy==<file> JVM parameter
AS HS ’10 29
Java security model: advantages/disadvantages
Java 2 security pros/cons (1)
Pros:
→ Permits controlled execution of less trusted code (compare
with ActiveX)
→ Permits fine-grained permission control
→ Attention is paid to security
→ Portability
→ “Instant installation”
→ Sun’s source is reviewable (not open source)
Contras:
→ Hard to prove correct:
– complex from a security point-of-view
– rapidly expanding/changing
– JVM + libraries lacks formal security model
→ Many internal interdependencies that often breaks the
security model (this shows how difficult it is to build a clean
reference monitor).
→ Complex dependencies on other systems like OS,
browsers, network (DNS), PKI …
AS HS ’10 31
Java 2 security cons (2)
→ Applets evade many security measures (e.g. most
firewalls). Breaches are widely demonstrated
→ Many areas show ad hoc solutions (i.e. doPrivileged()
amplifies rights!)
→ No standardized auditing tools (MS extension)
→ Reverse engineering of Java byte code is almost too
simple. It lowers the entry barrier for crackers.
→ The poor performance of the security tools may encourage
security-weakening “shortcuts”
→ Weak against denial-of-service and nuisances;
→ Insecure implementation of defaults (e.g. "null"
ClassLoader or SecurityManager);
→ Security policy management is too complex for end users
and support tools to administer it are almost useless;
→ Flexible policies accepted by users may permit hidden
breaching interactions.
AS HS ’10 32
Summary
•
Progression of Access Control Flexibility
– JDK 1.0: Sandbox + total trust of local applications
– JDK 1.1: Above + optional total trust with signature
– SDK 1.2: Above + Fine-grained access control
• Java 2 ProtectionDomains
– Checks call tree, by default intersection of permissions
– doPrivilege permits permissions to be re-enabled
• GuardedObject to protect specific objects
AS HS ’10 33
Bibliography
•
•
•
•
Li Gong, Inside Java 2 Platform Security (2nd Edition), 2003, Palo Alto,
CA: Addison-Wesley.
G. McGraw & E. Felten, Java Security: Hostile Applets, Holes, and
Antidotes, 1997, NY: John Wiley & Sons.
G. McGraw & E. Felten, Securing Java: Getting Down to Business with
Mobile Code, 1999, NY: John Wiley & Sons,
http://www.securingjava.com
Permissions in Java 2:
http://java.sun.com/j2se/1.5.0/docs/guide/security/p
ermissions.html
AS HS ’10 34