Developing With Jaas: Presented By Maciej Zawadzki

  • Uploaded by: ramsuri
  • 0
  • 0
  • April 2020
  • PDF

This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA


Overview

Download & View Developing With Jaas: Presented By Maciej Zawadzki as PDF for free.

More details

  • Words: 2,950
  • Pages: 46
Developing with JAAS

Presented by Maciej Zawadzki [email protected] Copyright  2002 Urbancode Software Development, Inc.

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

Copyright  2002 Urbancode Software Development, Inc.

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

Copyright  2002 Urbancode Software Development, Inc.

Outline • Introduction – – – –

What is JAAS Authentication vs. Authorization Subject Principal

• Authentication • Authorization

Copyright  2002 Urbancode Software Development, Inc.

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.

Authentication Authentication Service

User Name Password

Is the user who he says he is?

Andy

Authorization Some Action

Andy

Resource

Can this user perform this action on me?

Authorization Service

Copyright  2002 Urbancode Software Development, Inc.

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

The Subject in Detail Principal Principal Principal

Subject

Public Public Credential Public Credential Credential Private Private Credential Private Credential Credential

Copyright  2002 Urbancode Software Development, Inc.

Subject 1. package javax.security.auth; 2. public class Subject { 3. ... 4. 5. public Set getPrincipals() {} 6. public Set getPrincipals(Class c) {} 7. 8. public Set getPrivateCredentials() {} 9. public Set getPrivateCredentials(Class c) {} 10. 11. public Set getPublicCredentials() {} 12. public Set getPublicCredentials(Class c) {} 13. 14. public boolean isReadOnly() {} 15. public void setReadOnly() {} 16. }

Copyright  2002 Urbancode Software Development, Inc.

Principal 1. package java.security; 2. public interface Principal { 3. ... 4. public String getName(); 5. }

• 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. Copyright  2002 Urbancode Software Development, Inc.

Obtaining a Specific Principal from a Subject 1. 2. 3. 4. 5. 6. 7. 8.

// List the UserPrincipalExample 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.

Copyright  2002 Urbancode Software Development, Inc.

Outline • Introduction • Authentication • Authorization

Copyright  2002 Urbancode Software Development, Inc.

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

Pluggable Authentication Application

Login Context Login Modules NTLogin Module

UnixLogin Module

MyLogin Module

JndiLogin Module

Krb5Login Module

DbLogin Module

NT Authentication

Unix Authentication

Biometric Authentication

LDAP Server

Kerberos Authentication

RDBMS

Copyright  2002 Urbancode Software Development, Inc.

LoginConfiguration File Application1 { ModuleClass }; Application2 { ModuleClass ModuleClass }; other { ModuleClass ModuleClass };

Flag

ModuleOptions;

Flag Flag

ModuleOptions; ModuleOptions;

Flag Flag

ModuleOptions; ModuleOptions;

• The default implementation parses a configuration file in the above format • Configuration file specified via java.security.auth.login.config System parameter Copyright  2002 Urbancode Software Development, Inc.

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. Copyright  2002 Urbancode Software Development, Inc.

Authentication Overview 1.

2.

1. 2.

The application Authentication Participants creates a Login Login LoginContext and Context Configuration calls login() Application The LoginContext refers to the Login LoginConfiguration Login Module Callback Login to set up the Module Handler Module appropriate LoginModules The LoginContext delegates the authentication to the LoginModules The LoginModules use the CallbackHandler to communicate with the application

Copyright  2002 Urbancode Software Development, Inc.

Login Example 1. // Use the "Example" entry in the login configuration file 2. // to authenticate users. 3. LoginContext loginContext = null; 4. try { 5. loginContext = new LoginContext("Example", 6. new ExampleCallbackHandler()); 7. loginContext.login(); 8. } catch (AccountExpiredException e) { 9. ... 10. } catch (CredentialExpiredException e) { 11. ... 12. } catch (FailedLoginException e) { 13. ... 14. } catch (LoginException e) { 15. ... 16. } catch (Exception e) { 17. ... 18. }

Copyright  2002 Urbancode Software Development, Inc.

Login Example 1. 2. 3. 4. 5. 6. 7. 8. 9.

// 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()); }

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

Copyright  2002 Urbancode Software Development, Inc.

Creating a LoginContext 1. public class LoginContext { 2. public LoginContext(String name) { ... } 3. public LoginContext(String name, Subject subject) {...} 4. 5. public LoginContext(String name, 6. CallbackHandler handler) { ... } 7. public LoginContext(String name, Subject subject, 8. CallbackHandler handler) { ... } 9. 10. ... 11. }

• 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 Copyright  2002 Urbancode Software Development, Inc.

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.” Copyright  2002 Urbancode Software Development, Inc.

Logging In 1. 2. 3. 4. 5. 6.

public class LoginContext { ... public void login() throws LoginException { } public void logout() throws LoginException { } public Subject getSubject() { } }

• 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

Copyright  2002 Urbancode Software Development, Inc.

LoginModule 1. package javax.security.auth.spi; 2. public interface LoginModule { 3. public void initialize(Subject subject, 4. CallbackHandler callbackHandler, 5. Map sharedState, 6. Map options); 7. public boolean abort() throws LoginException; 8. public boolean commit() throws LoginException; 9. public boolean login() throws LoginException; 10. public boolean logout() throws LoginException; 11. }

• Two-phase authentication: – login() is 1st phase method – commit() and abort() are 2nd phase methods Copyright  2002 Urbancode Software Development, Inc.

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

Copyright  2002 Urbancode Software Development, Inc.

Custom LoginModule Example 1. public boolean login() 2. throws LoginException { 3. Callback[] callbacks = new Callback[2]; 4. callbacks[0] = new NameCallback("userName: "); 5. callbacks[1] = new PasswordCallback("password: ",false); 6. try { 7. callbackHandler.handle(callbacks); 8. userName = ((NameCallback) callbacks[0]).getName(); 9. char[] charPass = ((PasswordCallback) callbacks[1]) 10. .getPassword(); 11. if (charPass == null) charPass = new char[0]; 12. password = new String(charPassword); 13. } catch (IOException ioe) { 14. ... 15. } catch (UnsupportedCallbackException uce) { 16. ... 17. } 18. if (isUserAuthentic()) succeeded = true; 19. 20. return succeeded; 21. } Copyright  2002 Urbancode Software Development, Inc.

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 Copyright  2002 Urbancode Software Development, Inc.

CallbackHandler 1. package javax.security.auth.callback; 2. public interface CallbackHandler { 3. public void handle(Callback[] callbacks) 4. throws IOException, UnsupportedCallbackException; 5. }

Copyright  2002 Urbancode Software Development, Inc.

Custom CallbackHandler Example 1. public void handle(Callback[] callbacks) 2. throws IOException, UnsupportedCallbackException { 3. for (int i = 0; i < callbacks.length; i++) { 4. if (callbacks[i] instanceof TextOutputCallback) { 5. ... 6. } else if(callbacks[i] instanceof NameCallback) { 7. NameCallback nc = (NameCallback) callbacks[i]; 8. System.out.print(nc.getPrompt()); 9. System.out.flush(); 10. nc.setName(readLine()); 11. } else if(callbacks[i] instanceof PasswordCallback){ 12. PasswordCallback pc = (PasswordCallback) 13. callbacks[i]; 14. System.out.print(pc.getPrompt()); 15. System.out.flush(); 16. pc.setPassword(readLine().toCharArray()); 17. } else { 18. throw new UnsupportedCallbackException 19. (callbacks[i], "Invalid Callback"); 20. } 21. } 22. } Copyright  2002 Urbancode Software Development, Inc.

Custom LoginConfiguration 1. package javax.security.auth.login; 2. public abstract class Configuration { 3. ... 4. public AppConfigurationEntry[] 5. getAppConfigurationEntry(String name) {} 6. }

• 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

1. package javax.security.auth.login; 2. public class AppConfigurationEntry { 3. public ... getControlFlag() {} 4. public String getLoginModuleName() {} 5. public Map getOptions() {} 6. } Copyright  2002 Urbancode Software Development, Inc.

Custom LoginConfiguration 1. public AppConfigurationEntry[] getAppConfigurationEntry(String name) { 2. AppConfigurationEntry[] entries = new AppConfigurationEntry[1]; 3. 4. entries[0] = new AppConfigurationEntry( 5. ExampleLoginModule.class.getName(), 6. AppConfigurationEntry.LoginModuleControlFlag.REQUISITE, 7. new HashMap()); 8. 9. return entries; 10. }

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

Copyright  2002 Urbancode Software Development, Inc.

Outline • Introduction • Authentication • Authorization

Copyright  2002 Urbancode Software Development, Inc.

CodeSource Based Authorization • Before the integration of JAAS with Java security, authorization decisions were strictly based on the CodeSource

Code Source Based Authorization File System

Library X

Network Sockets

Trusted Library

System Properties

Applet

• A Trusted Library may be given access to sensitive resources while an Applet or another Library may have that access restricted. Copyright  2002 Urbancode Software Development, Inc.

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.

Code Source and Principal Based Authorization File System Network Sockets System Properties

Library X

Andy

Bart

• 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. Copyright  2002 Urbancode Software Development, Inc.

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.

CodeSource URL Code Source Certificate

ProtectionDomain Class

Code Source

Protection Domain

Principal

Copyright  2002 Urbancode Software Development, Inc.

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.

Authorization Context Stack Snapshot

Context

AccessController.checkPermission()

Class

PD

java.io.FileInputStream()

Class

PD

java.io.FileReader()

Class

PD

ReadTestFileUseCase.apply()

Class

PD

AuthorizationTestHarness.run()

Class

PD

...

Class

PD

• 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. Copyright  2002 Urbancode Software Development, Inc.

Permission 1. package java.security; 2. public abstract class Permission { 3. public Permission (String name) {} 4. public abstract boolean implies(Permission p) {} 5. public abstract boolean equals(Object o) {} 6. public String toString() {} 7. public PermissionCollection newPermissionCollection() {} 8. }

• 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. Copyright  2002 Urbancode Software Development, Inc.

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 Copyright  2002 Urbancode Software Development, Inc.

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

Policy Holds a Mapping of ProtectionDomain to Permissions Policy Protection Domain

Permission Collection

Permission Permission Permission

Protection Domain

Permission Collection

Permission Permission Permission

Protection Domain

Permission Collection

Permission Permission Permission

Copyright  2002 Urbancode Software Development, Inc.

Policy 1. grant [CodeBase ,] [Signedby <signers>,] 2. [Principal ] { 3. Permission [] 4. [, ] 5. [, signedBy <Signer_Name>]; 6. };

• 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= JVM parameter

• Can override the default policy file with: – -Djava.security.policy== JVM parameter Copyright  2002 Urbancode Software Development, Inc.

AccessController 1. MyPermission p = new MyPermission(fileName, "display"); 2. AccessController.checkPermission(p);

• 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) ;

Copyright  2002 Urbancode Software Development, Inc.

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.

Authorization Participants Access Controller

Access Control Context

Class

Code Source Principal

Protection Domain

Policy

Permission Collection

Permission Permission Permission

Copyright  2002 Urbancode Software Development, Inc.

AccessController 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.

package java.security; public final class AccessController { static public void checkPermission(Permission p) {} static public Object doPrivileged(PrivilegedAction pa) {} static public Object doPrivileged(PrivilegedAction pa, AccessControlContext ctx) static public Object doPrivileged(PrivilegedExceptionAction static public Object doPrivileged(PrivilegedExceptionAction AccessControlContext ctx) static public AccessControlContext getContext() {} }

{} pa){} pa, {}

Copyright  2002 Urbancode Software Development, Inc.

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

Using a PrivilegedAction Truncates the AccessControlContext Stack Snapshot

Context

AccessController.checkPermission()

Class

PD

java.io.FileInputStream()

Class

PD

java.io.FileReader()

Class

PD

Trusted Library

Class

PD

Your Application

Class

Your Application

Class

Copyright  2002 Urbancode Software Development, Inc.

PrivilegedAction 1. AccessController.doPrivileged( 2. new PrivilegedAction() { 3. public Object run() { 4. ... 5. return null; 6. } 7. });

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

Copyright  2002 Urbancode Software Development, Inc.

Associating a Subject with an Access Control Context 1. package javax.security.auth; 2. public class Subject { 3. ... 4. 5. static public Object doAs(Subject s, PrivilegedAction pa) {} 6. static public Object doAs(Subject s, PrivilegedExceptionAction pa){} 7. static public Object doAsPrivileged(Subject s, 8. PrivilegedAction pa) {} 9. static public Object doAsPrivileged(Subject s, 10. PrivilegedExceptionAction pa) {} 11.}

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

Copyright  2002 Urbancode Software Development, Inc.

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) Copyright  2002 Urbancode Software Development, Inc.

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

Copyright  2002 Urbancode Software Development, Inc.

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 

Copyright  2002 Urbancode Software Development, Inc.

Thank you! Maciej Zawadzki [email protected]

Copyright  2002 Urbancode Software Development, Inc.

Related Documents

Presented By
June 2020 41
Presented By
June 2020 39
Presented By
May 2020 38
Presented By
June 2020 34
Presented By
June 2020 25

More Documents from ""