Java security auth login configuration

Java security auth login configuration

The goal of this exercise is to learn how to use the Java Authentication and Authorization (JAAS) API to perform authentication.

Background for This Exercise

JAAS provides a standard pluggable authentication framework (PAM) for the Java platform. An application uses the JAAS API to perform authentication — the process of verifying the identity of the user who is using the application and gathering his identity information into a container called a subject . The application can then use the identity information in the subject along with the JAAS API to make authorization decisions, to decide whether the authenticated user is allowed to access protected resources or perform restricted actions. This exercise demonstrates JAAS Authentication. It does not demonstrate JAAS Authorization.

Resources for This Exercise

• Java Authentication and Authorization Service (JAAS) Reference Guide
• JAAS Tutorials
• JAAS Javadoc API documentation
  • javax.security.auth
  • javax.security.auth.callback
  • javax.security.auth.kerberos
  • javax.security.auth.login
  • javax.security.auth.spi
  • javax.security.auth.x500
  • Read the Jass.java sample code. The code performs the following tasks:
    1. Define a callback handler or use a predefined one.
    2. Create a LoginContext with a name that identifies which JAAS configuration entry to use.
    3. Perform the authentication.
    4. Define the task that the authenticated user is to perform.
    5. Perform the action as the authenticated user.
    6. Log out.

  Subject.doAs will run the code defined in MyAction as the authenticated user [lines 14-15]. This serves two purposes. First, code in MyAction that requires identity information for authentication to a service could get it from the subject. This exercise demonstrates this use. Second, if MyAction accesses any protected resources/operations, the identity information in the current subject would be used to make the corresponding access control decision. This second aspect is not covered in this exercise.

  This exercise introduced the main classes of the JAAS APIs: LoginContext and Subject . You learned how to use LoginContext to authenticate a user and collect its identity information in a Subject. You then learned how to use the Subject to perform an action as the authenticated user.

  Proceed to Exercise 2: Configuring JAAS for Kerberos Authentication to learn how to configure the sample application to use Kerberos for authentication.

  Exercise 2: Configuring JAAS for Kerberos Authentication

  The goal of this exercise is to learn how to configure a JAAS application to use Kerberos for authentication.

  Kerberos Background for This Exercise

  Kerberos is an Internet standard protocol for trusted-third party authentication defined in RFC 4120. It is available on most modern computing platforms today, including Solaris, Windows, and Linux.

  The Kerberos architecture is centered around a trusted authentication service called the key distribution center, or KDC. Users and services in a Kerberos environment are referred to as principals; each principal shares a secret (such as a password) with the KDC. A principal authenticates to Kerberos by proving to the KDC that it knows the shared secret. If the authentication is successful, the KDC issues a ticket-granting-ticket (TGT) to the principal. When the principal subsequently wants to authenticate to a service on the network, such as a directory service or a file service, (thereby, acting as a «client» of the service), it gives the TGT to the KDC to obtain a service ticket to communicate with the service. Not only does the service ticket indicate the identities of the client and service principals, it also contains a session key that can be used by the client and service to subsequently establish secure communication. To authenticate to the service, the client sends the service ticket to the service. When the service receives the ticket, it decodes it using the secret it shares with the KDC.

  In this architecture, a principal only authenticates directly (once) to the KDC. It authenticates indirectly to all other services via the use of service tickets. Service tickets are how the KDC vouches for the identity of a principal. The ability of a principal to access multiple secure services by performing explicit authentication only once is called single sign-on.

  JAAS Background for This exercise

  In JAAS, for a client principal, «logging into Kerberos» means acquiring the TGT and placing it in the Subject, so that it can be used for authentication with services that the client will access. For a service principal, «logging into Kerberos» means obtaining the secret keys that the service needs to decode incoming client authentication requests.

  Resources for This Exercise

  1. Examine the jaas-krb5.conf configuration file. This file contains two entries, one named client and one named server . The client entry indicates that the LoginContext must use the com.sun.security.auth.module.Krb5LoginModule . The server entry indicates that the LoginContext must use the same login module, and use keys from the sample.keytab file for the principal host/machineName.
  2. Determine the hostname of your machine by executing the hostname command.
  3. Edit this file and change the entry for server principal to use the name of your machine. For example, if your machine name is j1hol-001, this line in the configuration file should look like this:

  % java -Djava.security.auth.login.config=jaas-krb5.conf Jaas client

  You will be prompted for a password. You should see the following output. Replace password with a password that is secure.

  Kerberos password for test: password Authenticated principal: [test@J1LABS.EXAMPLE.COM] Performing secure action. 

  % java -Djava.security.auth.login.config=jaas-krb5.conf Jaas server

  Authenticated principal: [host/j1hol-001@J1LABS.EXAMPLE.COM] Performing secure action. 

  In this exercise, you learned how to configure a JAAS application to use a Kerberos login module, both as a client principal who enters his/her username/password interactively, and as a service principal who gets its keys from a keytab file.

  Proceed to Part II : Secure Communications using the Java SE Security API to learn how to establish secure communication channels using Java security APIs.

  Источник

  Class Configuration

  A Configuration object is responsible for specifying which LoginModules should be used for a particular application, and in what order the LoginModules should be invoked.

  A login configuration contains the following information. Note that this example only represents the default syntax for the Configuration . Subclass implementations of this class may implement alternative syntaxes and may retrieve the Configuration from any source such as files, databases, or servers.

  Each entry in the Configuration is indexed via an application name, Name, and contains a list of LoginModules configured for that application. Each LoginModule is specified via its fully qualified class name. Authentication proceeds down the module list in the exact order specified. If an application does not have a specific entry, it defaults to the specific entry for «other«.

  The Flag value controls the overall behavior as authentication proceeds down the stack. The following represents a description of the valid values for Flag and their respective semantics:

  1) Required - The LoginModule is required to succeed. If it succeeds or fails, authentication still continues to proceed down the LoginModule list. 2) 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 (authentication does not proceed down the LoginModule list). 3) Sufficient - The LoginModule is not required to succeed. If it does succeed, control immediately returns to the application (authentication does not proceed down the LoginModule list). If it fails, authentication continues down the LoginModule list. 4) Optional - The LoginModule is not required to succeed. If it succeeds or fails, authentication still continues to proceed down the LoginModule list.

  The overall authentication succeeds only if all Required and Requisite LoginModules succeed. If a Sufficient LoginModule is configured and succeeds, then only the Required and Requisite LoginModules prior to that Sufficient LoginModule need to have succeeded for the overall authentication to succeed. If no Required or Requisite LoginModules are configured for an application, then at least one Sufficient or Optional LoginModule must succeed.

  ModuleOptions is a space separated list of LoginModule -specific values which are passed directly to the underlying LoginModules. Options are defined by the LoginModule itself, and control the behavior within it. For example, a LoginModule may define options to support debugging/testing capabilities. The correct way to specify options in the Configuration is by using the following key-value pairing: debug=»true». The key and value should be separated by an ‘equals’ symbol, and the value should be surrounded by double quotes. If a String in the form, $, occurs in the value, it will be expanded to the value of the system property. Note that there is no limit to the number of options a LoginModule may define.

  The following represents an example Configuration entry based on the syntax above:

  This Configuration specifies that an application named, «Login», requires users to first authenticate to the com.sun.security.auth.module.UnixLoginModule, which is required to succeed. Even if the UnixLoginModule authentication fails, the com.sun.security.auth.module.Krb5LoginModule still gets invoked. This helps hide the source of failure. Since the Krb5LoginModule is Optional, the overall authentication succeeds only if the UnixLoginModule (Required) succeeds.

  Also note that the LoginModule-specific options, useTicketCache=»true» and ticketCache=$$tickets», are passed to the Krb5LoginModule. These options instruct the Krb5LoginModule to use the ticket cache at the specified location. The system properties, user.home and / (file.separator), are expanded to their respective values.

  There is only one Configuration object installed in the runtime at any given time. A Configuration object can be installed by calling the setConfiguration method. The installed Configuration object can be obtained by calling the getConfiguration method.

  If no Configuration object has been installed in the runtime, a call to getConfiguration installs an instance of the default Configuration implementation (a default subclass implementation of this abstract class). The default Configuration implementation can be changed by setting the value of the login.configuration.provider security property to the fully qualified name of the desired Configuration subclass implementation.

  Application code can directly subclass Configuration to provide a custom implementation. In addition, an instance of a Configuration object can be constructed by invoking one of the getInstance factory methods with a standard type. The default policy type is «JavaLoginConfig». See the Configuration section in the Java Security Standard Algorithm Names Specification for a list of standard Configuration types.

  Источник

  Читайте также:  How to work with json in java