1 / 35

JAVA AUTHENTICATION AND AUTHORIZATION SERVICE (JAAS)

JAVA AUTHENTICATION AND AUTHORIZATION SERVICE (JAAS). Authentication and Authorization. An authentication system is how you identify yourself to the computer. The goal behind an authentication system is to verify that the user is actually who they say they are.

gus
Télécharger la présentation

JAVA AUTHENTICATION AND AUTHORIZATION SERVICE (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. JAVA AUTHENTICATION AND AUTHORIZATION SERVICE (JAAS)

  2. Authentication and Authorization • An authenticationsystem is how you identify yourself to the computer. • The goal behind an authentication system is to verify that the user is actually who they say they are. • There are many ways of authenticating a user. Any combination of the following are good examples. • Password based authentication • Device based authentication • Biometric Authentication

  3. Authentication and Authorization • Once the system knows who the user is through authentication, authorization is how the system decides what the user can do. • initiate or progress a transaction, process or activity • Authorization is the process of granting permission to someone or something • in order to perform given actions. • This is where you say that user x has permission to access, say, a file or directory.

  4. Authentication and Authorization • An example: A web site that may have a number pages protected by a username/password mechanism. • Any user with valid credentials will be able to gain access to these pages (authentication), • But some of the users may be employees and have access to additional information on other pages not accessible by ordinary users (authorization). • Authentication and Authorization are two completely separate acts within the administration scheme. • A user may be authenticated but have no authorization. • Authentication may be performed by an entity completely separate of the area where authorization for access may reside. • For example, I may use SecureID to authenticate a user to access routers, • however the authorization for the router they are allowed to access resides in the router itself where the SecureID server is external of the router.

  5. Using JAAS Authentication Typically involves the following steps: • Create a LoginContext • Optionally pass a CallbackHandler to the LoginContext, for gathering or processing authentication data • Perform authentication by calling the LoginContext's login() method • Perform privileged actions using the returned Subject (assuming login succeeds) Here's a minimal example:  LoginContextlc = new LoginContext("MyExample");    try {lc.login();    } catch (LoginException) {  // Authentication failed.    }// Authentication successful, we can now continue.    // We can use the returned Subject if we like.  Subject sub = lc.getSubject();Subject.doAs(sub, new MyPrivilegedAction());

  6. During initialization, the LoginContext finds the configuration entry "MyExample" in a JAAS configuration file (which we configured) and • determines which LoginModules to load • During login, the LoginContext calls each LoginModule's login() method • Each login() method performs the authentication or enlists a CallbackHandler • The CallbackHandler uses one or more Callbacks to interact with the user and gather input • A new Subject instance is populated with authentication details such as Principals and credentials

  7. JAAS configuration

  8. Java 2 Security Model • The ability to grant specific permissions to a particular piece of codeabout accessing specific resources on the client, depending on the signer of the code and/or the location from which the code was loaded.

  9. JAAS classes and interfaces • Common • Subject, • Principal, • credential (credential is not any specific class, but can be any object) • Authentication • LoginContext, • LoginModule, • CallbackHandler, • Callback • Authorization • Policy, • AuthPermission, • PrivateCredentialPermission • Most of these classes and interfaces are in the javax.security.auth package's subpackages, with some prebuilt implementations in the com.sun.security.auth package, included only in J2SE 1.4.

  10. Common Interface I • The Subject class represents an authenticated entity: • an end-user or administrator, • a Web service, device, • another process. • The class contains three sets of security information types: • Identities: In the form of one or more Principals • Public credentials: Such as name or public keys • Private credentials: Like passwords or private keys

  11. An Explanation of Common Classes: • A Subject may be any entity, such as a person or service. • Once authenticated, a Subject is populated with associated identities, or Principals. • A Subject may have many Principals. • For example, a person may have a name Principal ("Jane Doe") • and a Social Security Number Principal ("111-22-3333"), that distinguish it from other Subjects. • The getPrincipals() method retrieves the Principals associated with a Subject. • The static method doAs() in Subject achieves the effect of having an action run as the subject. • Based on whether this action is authorized, the action completes successfully or generates an exception.

  12. JAAS programming model To authenticate and authorize a Subject, these steps are performed: • An application instantiates a LoginContext. • The LoginContext consults a Configuration file, along the lines of ones discussed above, to load the LoginModules configured for that application. • The application invokes the LoginContext's login() method. • The login() method invokes the loaded LoginModules. Each LoginModule attempts to authenticate the Subject. Upon success, LoginModules associate relevant Principals and credentials with the Subject. • The LoginContext returns the authentication status to the application. • If authentication succeeds, the application retrieves the authenticated Subject from the LoginContext. • Upon successful authentication of a Subject, fine-grained access controls can be placed upon that Subject by invoking the Subject.doAs() methods. The permissions granted to that Subject are configured in a JAAS policy.

  13. The following code outline illustrates how application code uses the JAAS framework: // Instantiate a login context    LoginContext context = new LoginContext("name", CallbackHandler); // Authenticate the subject    context.login(); // Retrieve the authenticated subject    Subject subject = context.getSubject();  // Enforce Access Controls    Subject.doAs(subject, action); To implement a new login module, follow these suggested steps: • Understand the authentication technology • Name the LoginModule implementation • Implement the abstract LoginModule method • ompile the LoginModule • Configure and test the LoginModule • Document and package the LoginModule implementation

  14. static doAs method in the Subject class • When using JAAS authentication to authenticate a user, a subject is created to represent the authenticated user. • A subject is comprised of a set of principals, • where each principal represents an identity for that user. • We can grant permissions in the policy to specific principals. • After the user has been authenticated, the application can associate the subject with the current access control context. • For each subsequent security-checked operation, • The Java run time automatically determines • whether the policy grants the required permission only to a specific principal. • If so, the operation is allowed only if the subject associated with the access control context contains the designated principal.

  15. static doAs method in the Subject class • Associate a subject with the current access control context, • by calling the static doAs method from the subject class, • passing it an authenticated subject andjava.security.PrivilegedAction or java.security.PrivilegedExceptionAction. • The doAs method associates the provided subject with the current access control context. Then; • invokes the run method from the action. • The run method implementation contains all the code executed as the specified subject. • The action executes as the specified subject.

  16. Subject.doAs(subject, newjava.security.PrivilegedAction() { Public Object run() { //the subject object is associated with the context of the current execution thread java.security.AccessController.doPrivileged( new java.security.PrivilegedAction() { public Object run() { // Subject was cut off from the current thread context //Within the run method of a doPrivileged action block, // the subject objectis removed from the thread context return null; } });// Subject is associated with the current thread context return null; } }); • Since doPrivileged blocks can be placed anywhere along the execution path and instrumented quite often in a server environment, • the run-time behavior of a doAs action block becomes difficult to manage.

  17. Class java.security.AccessController • Documentation changedfrom oldto new • The AccessController class is used for access control operations and decisions. • More specifically the AccessController class is used for three purposes: • to decide whether an access to a critical system resource is to be allowed or denied based on the security policy currently in effect • to mark code as being "privileged" • thus affecting subsequent access determinations • to obtain a "snapshot" of the current calling context • so access-control decisions from a different context can be made with respect to the saved context.

  18. ChangedMethodsin classjava.security.AccessController Documentation changed from oldto new • Object doPrivileged(PrivilegedExceptionAction) • Performs the specified PrivilegedExceptionAction with privileges enabled. • Object doPrivileged(PrivilegedExceptionAction, AccessControlContext) • Performs the specified PrivilegedExceptionAction with privileges enabled and restricted by the specified AccessControlContext.

  19. publicClass Object • Class Object is the root of the class hierarchy. • Every class has Object as a superclass. • All objects, including arrays, implement the methods of this class. • public Object() constructor • public interface Runnable • When an object implementing interface Runnable is used to create a thread, starting the thread causes the object's run method to be called in that separately executing thread. • public void run() • The Runnable interface should be implemented by any class whose instances are intended to be executed by a thread. The class must define a method of no arguments called run. • his interface is designed to provide a common protocol for objects that wish to execute code while they are active

  20. Common Interface II • Principals represent Subject identities. • They implement the java.security.Principal interface (which predates JAAS) and java.io.Serializable. • A Subject's most important method is getName(), which returns an identity's string name. • Since a Subject instance contains an array of Principals, • it can thus have multiple names. • Because a social security number, login ID, email address, and so on, can all represent one user, multiple identities prove common in the real world

  21. Common Interface II • The last elementcredential, is not a class or an interface, but can be any object. • Credentials can include any authentication artifact, • such as a ticket, key, or password • specific security systems might require. • The Subject class maintains unique Sets of private and public credentials, • which can be retrieved with methods such as • getPrivateCredentials() and • getPublicCrendentials(). • These methods are more often used by security subsystems than at the application layer.

  22. Authentication: LoginContext • The application layer uses LoginContext as its primary class for authenticating Subjects. • LoginContext also represents where JAAS's dynamic pluggability comes into play, • because when you construct a LoginContext, • you specify a named configuration to load. • The LoginContext typically loads the configuration information from a text file, • which in turn tells the LoginContext which LoginModules to use during login.

  23. Explanation of Authentication Classes • The LoginContext class provides the basic methods to authenticate Subject • The LoginContext class also provides a way to develop an application independent of the underlying authentication technology using a configuration file. • Actual authentication occurs with a call to the login() method. • The LoginModule interface allows you to implement various authentication technologies that can be plugged under an application. • Its important methods include: login() ,commit() ,abort(), logout() • The CallbackHandler communicates with the user to obtain authentication information using callbacks. • The abstract Policy class represents the system-wide JAAS access-control policy.

  24. LoginContext methods • login() :Performs login, a relatively complex step that invokes all LoginModules specified for this configuration. • If it succeeds, it creates an authenticated Subject. • If it fails, it throws a LoginException. • getSubject() :Returns the authenticated Subject • logout() :Logs out the authenticated Subject and removes its Principals and credentials.

  25. Authentication: LoginModule • LoginModule is the interface to specific authentication mechanisms. • J2SE 1.4 ships with a set of ready-to-use LoginModules, • JndiLoginModule: Verifies against a directory service configured under JNDI (Java Naming and Directory Interface) • Krb5LoginModule :Authenticates using Kerberos protocols • NTLoginModule :Uses the current user's NT security information to authenticate

  26. LoginModule • Modules can be configured via configuration files. A sample entry might look like: Login1 {    sample.SampleLoginModule required debug=true;}; • In this case, only one module performs the authentication. • An attempt by Login1 to authenticate a Subject will succeed if and only if the SampleLoginModule succeeds. • In that code , required represents a LoginModuleControlFlag

  27. LoginModuleControlFlags • Required: The login module must succeed. Regardless of whether it succeeds or fails, however, authentication still proceeds down the login module list. • Requisite: The login module must succeed. If login succeeds, authentication continues down. However, if it fails, control returns immediately to the application. • Sufficient: The module doesn't have to succeed. If it does succeed, control immediately returns to the application. • Optional: This login module doesn't have to succeed. Whether it succeeds or fails, authentication still proceeds down the login module list

  28. Overall authentication • Overall authentication is governed by the individual modules and their LoginModuleControlFlag entry. p indicates pass, f indicates fail, and * indicates don't care entries. ModuleCriterionPass/Fail SampleLoginModuleRequired p p p p f f f f NTLoginModuleSufficientp f f f p f SmartCardRequisite* p p f * p p f KerberosOptional* p f * * p f * Overallauthenticationp p p f f f f f Overall authentication for a stack-based authentication policy

  29. What is Kerberos? • A network authentication protocol • Provides strong authentication • for client/server applications • by using secret-key cryptography • created by MIT as a solution to network security problems • uses strong cryptography • a client can prove its identity to a server (and vice versa) across an insecure network connection. • After Kerberos has been used by a client and serverto prove their identity, • all of their communications can also be encrypted to assure the privacy and data integrity http://web.mit.edu/kerberos/dist/index.html http://web.mit.edu/kerberos/kfw-2.6/kfw-2.6.1/relnotes.html

  30. JAAS: Pluggableauthentication

  31. JAAS authorization • Once the user executing the code has been authenticated, the JAAS authorization component works in conjunction with the existing Java 2 CodeSource-based access control model. • JAAS policy extends the Java 2 policy with the relevant Subject-based information. • Therefore, permissions recognized and understood in Java 2 • java.io.FilePermission and java.net.SocketPermissionare equally understood and recognized by JAAS. • Although the JAAS security policy physically resides separately from the existing Java 2 security policy, • the two policies should be treated as one logical policy.

  32. An extension to the Java 2 policy file syntax grant signedBy "alias", codeBase "URL",    principal principalClass "principalName",    principal principalClass "principalName",    …… {    permission Type "name "action",         signedBy "alias";    permission Type "name "action",        signedBy "alias";   ....   };An example entry:  grant CodeBase "http://foo.com", Signedby "foo",        Principal com.sun.security.auth.NTPrincipal "admin" {            permission java.io.FilePermission "c:/user/admin", "read, write";    }; //Notice that the policy file entries include a Principal entry, the basis for user-based authentication.

  33. JAAS classes • The JAAS classes and interfaces reside in the following packages: javax.security.auth javax.security.auth.callback javax.security.auth.login javax.security.auth.spi • The classes and interfaces can be categorized as: • Common classes: Subject ,Principal , Credential • Authentication classes: LoginContext , LoginModule interface , Callback, CallbackHandler • Authorization classes: Policy , AuthPermission , PrivateCredentialPermission

  34. Running the Sample Program with the Login Utility The JAAS 1.0 kit includes a sample program at http://java.sun.com/j2se/1.4.2/docs/guide/security/jgss/tutorials/LoginSample.html#PF To run the sample, follow all instructions at the page above, and refer to the kit's policy files, command lines, and other relevant material.

  35. The sample program first instantiates a LoginContext. • The LoginContext consults the login configuration, which in this example points to a single module: SampleLoginModule. • The SampleLoginModule, loaded to perform the authentication, prompts for a username and password. • Entering "testUser" for the username and "testPassword" for the password, the SampleLoginModule associates a SamplePrincipal (with "testUser" as its name) with the current Subject, and then • executes the SampleAction as that Subject (by calling Subject.doAs). • The SampleAction, a privileged action, attempts to access two System properties (java.home and user.home), and also • attempts to access the file foo.txt in the current working directory. • This process will succeed only for the appropriate users, thereby accomplishing user-based authentication

More Related