Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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