1 / 46

Developing with JAAS

Understand JAAS, its components, and implementation in J2SE. Learn about Authentication vs. Authorization, Subjects, Principals, and how to use JAAS with code examples.

dregina
Download Presentation

Developing with JAAS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Developing with JAAS Presented by Maciej Zawadzki mbz@urbancode.com

  2. What is JAAS • Java Authentication and Authorization Service • Introduced as an optional package in J2SE 1.3 • Integrated into J2SE 1.4 • Implements a Java Pluggable Authentication Module (PAM) framework • Access decisions are based on CodeSource and the user running the code

  3. Goals • JAAS is an extensive and complicated library. • The goals for this presentation are: • To give an overview JAAS and its constituent parts and illustrate how they all work together • Provide enough information that you will be able to decide when it is appropriate to use JAAS • Provide an introduction on how to use JAAS; code examples to help you get started

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

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

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

  7. Subject

  8. Principal • A Principal identifies a Subject. The Subject can 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.

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

  10. Outline • Introduction • Authentication • Authorization

  11. Pluggable Authentication Modules • An application using JAAS for authentication can remain independent of the underlying authentication technology.

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

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

  14. 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 Authentication Overview

  15. Login Example

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

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

  18. 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.<name>”

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

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

  21. LoginModules in J2SE 1.4 • JndiLoginModule – Authenticates against an LDAP tree • Krb5LoginModule – Authenticates against a Kerberos domain • UnixLoginModule – Authenticates against Unix security

  22. Custom LoginModule Example

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

  24. CallbackHandler

  25. Custom CallbackHandler Example

  26. Custom LoginConfiguration • javax.security.auth.login.Configurationis an abstract Class used to specify which LoginModules should be used to Authenticate a user for a particular application

  27. Custom LoginConfiguration • You can configure the security system to use your own Configuration implementation by specifying the login.configuration.provider property in the <JRE_HOME>/lib/security/java.security file.

  28. Outline • Introduction • Authentication • Authorization

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

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

  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. 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. AccessControlContext – a Context for Authorization Decisions

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

  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. Custom Policy • You can substitute your own Policy implementation for the default one in one of two ways: • At runtime by calling Policy.setPolicy() • By changing the value of policy.provider property in <JRE_HOME>/lib/security/java.security • The specified class name must point to a subclass of Policy, and • The specified class must be in the boot classpath • Example included (you must change the java.security property on your JRE)

  44. Downloads • All source code is included on your CDs • You can check http://www.urbancode.com/presentations/ for updates

  45. Evaluations • Please fill out your speaker evaluations and drop them off at the registration desk • Please fill out the comments: • What was the best part of the presentation • What part put you most to sleep 

  46. Thank you! Maciej Zawadzki mbz@urbancode.com

More Related