Developing with JAAS

1
Developing with JAAS
Selma Tekir
2
Outline

• Introduction
• What is JAAS
• Authentication vs. Authorization
• Subject
• Principal
• Authentication
• Authorization

3
What Is JAAS

• Java authentication and authorization service
• Implements a java Pluggable authentication module
  (PAM) framework
• Access decisions are based on CodeSource and the
  user running the code

4
Authentication vs. Authorization

• Authentication is the process of verifying the
  users identity. Typically this entails
  obtaining a user name and a password or some
  other credential from the user.
• Authorization is the process of verifying whether
  a user has access to protected resources.

5
Overview of the Subject

• The Subject is a container for associated
  Principals, Public Credentials (public keys), and
  Private Credentials (passwords, private keys).

6
Subject
7
Principal

• A Principal identifies a Subject. The Subject
  can be a person, a corporation, and application,
  etc.
• A single Subject may have many Principals that
  serve to identify the entity. For example, a
  user can have a user name principal, an employee
  id principal, social security number principal,
  etc.

8
Obtaining a Specific Principal from a Subject

• 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.

9
Outline

• Introduction
• Authentication
• Authorization

10
Pluggable Authentication Modules

• An application using JAAS for authentication can
  remain independent of the underlying
  authentication technology.

11
LoginConfiguration File

• The default implementation parses a configuration
  file in the above format
• Configuration file specified via
  java.security.auth.login.config System parameter

12
LoginConfiguration Control Flags

• Required The LoginModule is required to
  succeed. Regardless of success, authentication
  proceeds to next LoginModule
• Requisite Is required to succeed. If succeeds,
  authentication proceeds. If fails, control
  returned.
• Sufficient Not required to succeed. If
  suceeds, control returned. If fails,
  authentication proceeds.
• Optional Not required to succeed. Regardless
  of success, authentication proceeds.
• Overall authentication succeeds if all Required
  and Requisite modules before a Sufficient module
  succeed.
• If not Required or Requisite modules are
  configured, then at least one Sufficient or
  Optional module must succeed.

13
Authentication Overview

• The application creates a LoginContext and calls
  login()
• The LoginContext refers to the LoginConfiguration
  to set up the appropriate LoginModules

• The LoginContext delegates the authentication to
  the LoginModules
• The LoginModules use the CallbackHandler to
  communicate with the application

14
Login Example
15
Login Example

• Once the login succeeds we can get the principal
  from the LoginContext and get the authenticated
  Principals from the Subject.

16
Creating a LoginContext

• 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

17
Creating a LoginContext

• The constructors without a CallbackHandler
  either
• Rely on the default CallbackHandler specified in
  the java.security file under property named
  auth.login.defaultCallbackHandler
• Do not use a CallbackHandler and rely on the
  LoginModules to have another means of obtaining
  the information
• Callers of a LoginContext constructor require an
  AuthPermission with target createLoginContext.ltna
  megt

18
Logging In

• Authentication occurs with a call to the login()
  method
• The login() method invokes all the configured
  LoginModules to perform authentication
• When authentication succeeds, the Subject can be
  retrieved using the getSubject() method
• The logout() method logs out the Subject and
  removes its authenticated Principals
• NTLoginModule Authenticates against Windows
  Security Domain

19
LoginModule

• Two-phase authentication
• login() is 1st phase method
• commit() and abort() are 2nd phase methods

20
LoginModules in J2SE 1.4

• JndiLoginModule Authenticates against an LDAP
  tree
• Krb5LoginModule Authenticates against a
  Kerberos domain
• UnixLoginModule Authenticates against Unix
  security

21
Custom LoginModule Example
22
Callbacks

• javax.security.auth.callback.Callback Marker
  interface used to indicate a callback.
• Callbacks provide a means for the underlying
  authentication implementation to communicate with
  the application and obtains security data such as
  user name and password as well as provide
  information such as error and warning messages.
• Included callbacks
• NameCallback
• PasswordCallback
• TextOutputCallback
• TextInputCallback
• ChoiceCallback
• ConfirmationCallback
• LanguageCallback

23
CallbackHandler
24
Custom CallbackHandler Example
25
Custom LoginConfiguration

• javax.security.auth.login.Configuration is an
  abstract Class used to specify which LoginModules
  should be used to Authenticate a user for a
  particular application

26
Custom LoginConfiguration

• You can configure the security system to use your
  own Configuration implementation by specifying
  the login.configuration.provider property in the
  ltJRE_HOMEgt/lib/security/java.security file.

27
Authentication
28
Outline

• Introduction
• Authentication
• Authorization

29
CodeSource Based 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.

30
CodeSource and Principal Based 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.

31
CodeSource 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.

32
AccessControlContext a Context for
Authorization Decisions

• 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.

• 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. This is the principle of
  least privilege.

33
Permission

• Permissions represent access to resources.
• All Permission object have a name. The meaning
  of the name parameter is implementation
  dependent. Typically the name identifies the
  resource to be accessed.

34
Permission

• The implies() method is implementation dependent.
  A permission p1 implies permission p2 if the
  grant of p1 is also meant to grant p2.
• Additional parameter called actions can be used
  to identify the type of access to the resource
  allowed.
• New Permissions are subclassed from Permission or
  from one of its existing subclasses such as
  java.security.BasicPermission.
• A special permission exists to indicate
  unrestricted access to all resource
  java.security.AllPermission

35
Policy

• The mapping between PDs and associated
  Permissions is stored by the Policy.
• Policy is a singleton.

36
Policy

• 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 ltJRE_HOMEgt/lib/security
  /java.policy
• Can provide supplemental policy file location via
  
• -Djava.security.policyltfilegt JVM parameter
• Can override the default policy file with
• -Djava.security.policyltfilegt JVM parameter

37
AccessController

• Your code would verify that the current context
  has a permission by creating a new instance of
  the permission in question and calling
  AccessController.checkPermission(p)

38
AccessController

• The AccessController embodies the access control
  algorithm.
• It obtains the current AccessControlContext,
  which has an array of PDs and then for each PD
  checks whether the PD has the requested
  permission.

39
AccessController
40
PrivilegedAction

• When a trusted library invokes a
  PrivilegedAction, the permissions of PDs in the
  call stack prior to the PrivilegedAction do not
  get checked.

41
PrivilegedAction

• Invoking a privileged action is done via a static
  method on the AccessController.
• PrivilegedExceptionAction can throw an Exception.
• Methods invoking a PrivilegedAction should not
  return references to resources.

42
Associating a Subject with an Access Control
Context

• To associate a Subject with the current execution
  context, one of the Subject.doAs() methods must
  be used.

43
Authorization
44
Conclusion

• JAAS is powerful and pluggable
• Beyond JAAS (Instance based security)