![]() | Documentation Contents |
The JavaTM Authentication and Authorization Service (JAAS) was introduced as an optional package (extension) to the JavaTM 2 SDK, Standard Edition (J2SDK), v 1.3. JAAS was integrated into the J2SDK 1.4.
JAAS can be used for two purposes:
- for authentication of users, to reliably and securely determine who is currently executing Java code, regardless of whether the code is running as an application, an applet, a bean, or a servlet; and
- for authorization of users to ensure they have the access control rights (permissions) required to do the actions performed.
JAAS implements a Java version of the standard Pluggable Authentication Module (PAM) framework. See Making Login Services Independent from Authentication Technologies for further information.
Traditionally Java has provided codesource-based access controls (access controls based on where the code originated from and who signed the code). It lacked, however, the ability to additionally enforce access controls based on who runs the code. JAAS provides a framework that augments the Java security architecture with such support.
JAAS authentication is performed in a pluggable fashion. This permits applications to remain independent from underlying authentication technologies. New or updated authentication technologies can be plugged under an application without requiring modifications to the application itself. Applications enable the authentication process by instantiating a
LoginContextobject, which in turn references aConfigurationto determine the authentication technology(ies), orLoginModule(s), to be used in performing the authentication. TypicalLoginModules may prompt for and verify a username and password. Others may read and verify a voice or fingerprint sample.Once the user or service executing the code has been authenticated, the JAAS authorization component works in conjunction with the core Java SE access control model to protect access to sensitive resources. Unlike in the J2SDK 1.3 and earlier, where access control decisions are based solely on code location and code signers (a
CodeSource), in the J2SDK 1.4 access control decisions are based both on the executing code'sCodeSourceand on the user or service running the code, who is represented by aSubjectobject. TheSubjectis updated by aLoginModulewith relevantPrincipals and credentials if authentication succeeds.Who Should Read This Document
This document is intended for experienced developers who require the ability to design applications constrained by a
CodeSource-based andSubject-based security model. It is also intended to be read by LoginModule developers (developers implementing an authentication technology) prior to reading the JAAS LoginModule Developer's Guide.You may wish to first read the JAAS Authentication and JAAS Authorization tutorials to get an overview of how to use JAAS and to see sample code in action, and then return to this document for further information.
Related Documentation
This document assumes you have already read the following:
A supplement to this guide is the JAAS LoginModule Developer's Guide, intended for experienced programmers who require the ability to write a
LoginModuleimplementing an authentication technology.If you wish to learn more about the standard Pluggable Authentication Module (PAM) framework (JAAS implements a Java version of PAM), see Making Login Services Independent from Authentication Technologies.
The following tutorials for JAAS authentication and authorization can be run by everyone:
Similar tutorials for JAAS authentication and authorization, but which demonstrate the use of a Kerberos LoginModule and thus which require a Kerberos installation, can be found at
These two tutorials are a part of the Java GSS-API and JAAS sequence of tutorials that utilize Kerberos as the underlying technology for authentication and secure communication.
The JAAS-related core classes and interfaces can be broken into three categories: Common, Authentication, and Authorization.
- Common Classes
- Subject, Principal, Credential (actually, any Object)
- Authentication Classes and Interfaces
- Authorization Classes
Common Classes
Common classes are those shared by both the JAAS authentication and authorization components.The key JAAS class is
javax.security.auth.Subject, which represents a grouping of related information for a single entity such as a person. It encompasses the entity's Principals, public credentials, and private credentials.Note that the
java.security.Principalinterface is used to represent a Principal. Also note that a credential, as defined by JAAS, may be any Object.Subject
To authorize access to resources, applications first need to authenticate the source of the request. The JAAS framework defines the term subject to represent the source of a request. A subject may be any entity, such as a person or a service. Once the subject is authenticated, ajavax.security.auth.Subjectis populated with associated identities, orPrincipals. ASubjectmay have manyPrincipals. For example, a person may have a namePrincipal("John Doe") and a SSNPrincipal("123-45-6789"), which distinguish it from other subjects.A
Subjectmay also own security-related attributes, which are referred to as credentials. Sensitive credentials that require special protection, such as private cryptographic keys, are stored within a private credentialSet. Credentials intended to be shared, such as public key certificates, are stored within a public credentialSet. Different permissions (described below) are required to access and modify the different credentialSets.Subjects are created using these constructors:
public Subject(); public Subject(boolean readOnly, Set principals, Set pubCredentials, Set privCredentials);The first constructor creates aSubjectwith empty (non-null)Sets ofPrincipals and credentials. The second constructor creates aSubjectwith the specifiedSets ofPrincipals and credentials. It also has a boolean argument which can be used to make theSubjectread-only. In a read-onlySubject, thePrincipaland credentialSets are immutable.An application writer does not have to instantiate a
Subject. If the application instantiates aLoginContextand does not pass aSubjectto theLoginContextconstructor, theLoginContextinstantiates a new emptySubject. See the LoginContext section.If a
Subjectwas not instantiated to be in a read-only state, it can be set read-only by calling the following method:public void setReadOnly();Ajavax.security.auth.AuthPermissionwith target "setReadOnly" is required to invoke this method. Once in a read-only state, any attempt to add or removePrincipals or credentials will result in anIllegalStateExceptionbeing thrown.The following method may be called to test a
Subject's read-only state:public boolean isReadOnly();To retrieve the
Principals associated with a Subject, two methods are available:public Set getPrincipals(); public Set getPrincipals(Class c);The first method returns all
Principals contained in theSubject, while the second method only returns thosePrincipals that are an instance of the specified Classc, or an instance of a subclass of Classc. An empty set will be returned if theSubjectdoes not have any associatedPrincipals.To retrieve the public credentials associated with a
Subject, these methods are available:public Set getPublicCredentials(); public Set getPublicCredentials(Class c);The behavior of these methods is similar to that for the
getPrincipalsmethods, except in this case the public credentials are being obtained.To access private credentials associated with a
Subject, the following methods are available:public Set getPrivateCredentials(); public Set getPrivateCredentials(Class c);The behavior of these methods is similar to that for the
getPrincipalsandgetPublicCredentialsmethods.To modify or operate upon a
Subject'sPrincipalSet, public credentialSet, or private credentialSet, callers use the methods defined in thejava.util.Setclass. The following example demonstrates this:Subject subject; Principal principal; Object credential; . . . // add a Principal and credential to the Subject subject.getPrincipals().add(principal); subject.getPublicCredentials().add(credential);Note: An
AuthPermissionwith target "modifyPrincipals", "modifyPublicCredentials", or "modifyPrivateCredentials" is required to modify the respectiveSets. Also note that only the sets returned via thegetPrincipals(),getPublicCredentials(), andgetPrivateCredentials()methods with no arguments are backed by theSubject's respective internal sets. Therefore any modification to the returned set affects the internal sets as well. The sets returned via thegetPrincipals(Class c),getPublicCredentials(Class c), andgetPrivateCredentials(Class c)methods are not backed by theSubject's respective internal sets. A new set is created and returned for each such method invocation. Modifications to these sets will not affect theSubject's internal sets.In order to iterate through a Set of private credentials, you need a
javax.security.auth.PrivateCredentialPermissionto access each credential. See thePrivateCredentialPermissionAPI documentation for further information.A
Subjectmay be associated with anAccessControlContext(see thedoAsanddoAsPrivilegedmethod descriptions below). The following method returns theSubjectassociated with the specifiedAccessControlContext, ornullif noSubjectis associated with the specifiedAccessControlContext.public static Subject getSubject(final AccessControlContext acc);An
AuthPermissionwith target "getSubject" is required to callSubject.getSubject.The
Subjectclass also includes the following methods inherited fromjava.lang.Object.public boolean equals(Object o); public String toString(); public int hashCode();The doAs methods for performing an action as a particular Subject
The following static methods may be called to perform an action as a particularSubject:public static Object doAs(final Subject subject, final java.security.PrivilegedAction action); public static Object doAs(final Subject subject, final java.security.PrivilegedExceptionAction action) throws java.security.PrivilegedActionException;Both methods first associate the specified
subjectwith the current Thread'sAccessControlContext, and then execute theaction. This achieves the effect of having theactionrun as thesubject. The first method can throw runtime exceptions but normal execution has it returning an Object from therunmethod of itsactionargument. The second method behaves similarly except that it can throw a checked exception from itsPrivilegedExceptionAction runmethod. AnAuthPermissionwith target "doAs" is required to call thedoAsmethods.Here is an example utilizing the first
doAsmethod. Assume that someone named "Bob" has been authenticated by aLoginContext(see the LoginContext section) and as a result aSubjectwas populated with aPrincipalof classcom.ibm.security.Principal, and thatPrincipalhas the name "BOB". Also assume that a SecurityManager has been installed, and that the following exists in the access control policy (see the Policy section for more details on the policy file).// grant "BOB" permission to read the file "foo.txt" grant Principal com.ibm.security.Principal "BOB" { permission java.io.FilePermission "foo.txt", "read"; };Here is the sample application code:
class ExampleAction implements java.security.PrivilegedAction { public Object run() { java.io.File f = new java.io.File("foo.txt"); // the following call invokes a security check if (f.exists()) { System.out.println("File foo.txt exists"); } return null; } } public class Example1 { public static void main(String[] args) { // Authenticate the subject, "BOB". // This process is described in the // LoginContext section. Subject bob; // Set bob to the Subject created during the // authentication process // perform "ExampleAction" as "BOB" Subject.doAs(bob, new ExampleAction()); } }During execution,
ExampleActionwill encounter a security check when it makes a call tof.exists(). However, sinceExampleActionis running as "BOB", and the policy (above) grants the necessaryFilePermissionto "BOB", theExampleActionwill pass the security check. If thegrantstatement in the policy is altered (adding an incorrectCodeBaseor changing thePrincipalto "MOE", for example), then aSecurityExceptionwill be thrown.The doAsPrivileged methods
The following methods also perform an action as a particular
Subject.public static Object doAsPrivileged( final Subject subject, final java.security.PrivilegedAction action, final java.security.AccessControlContext acc); public static Object doAsPrivileged( final Subject subject, final java.security.PrivilegedExceptionAction action, final java.security.AccessControlContext acc) throws java.security.PrivilegedActionException;An
AuthPermissionwith target "doAsPrivileged" is required to call thedoAsPrivilegedmethods.doAs vs. doAsPrivileged
The
doAsPrivilegedmethods behave exactly the same as thedoAsmethods, except that instead of associating the providedSubjectwith the current Thread'sAccessControlContext, they use the providedAccessControlContext. In this way, actions can be restricted byAccessControlContexts different from the current one.An
AccessControlContextcontains information about all the code executed since theAccessControlContextwas instantiated, including the code location and the permissions the code is granted by the policy. In order for an access control check to succeed, the policy must grant each code item referenced by theAccessControlContextthe required permissions.If the
AccessControlContextprovided todoAsPrivilegedisnull, then the action is not restricted by a separateAccessControlContext. One example where this may be useful is in a server environment. A server may authenticate multiple incoming requests and perform a separatedoAsoperation for each request. To start eachdoAsaction "fresh," and without the restrictions of the current serverAccessControlContext, the server can calldoAsPrivilegedand pass in anullAccessControlContext.Principals
As mentioned previously,Principals may be associated with aSubjectif authentication is successful.Principals representSubjectidentities, and must implement thejava.security.Principalandjava.io.Serializableinterfaces. The Subject section describes ways to update thePrincipals associated with aSubject.Credentials
Public and private credential classes are not part of the core JAAS class library. Any class can represent a credential. Developers, however, may elect to have their credential classes implement two interfaces related to credentials:RefreshableandDestroyable.Refreshable
The
javax.security.auth.Refreshableinterface provides the capability for a credential to refresh itself. For example, a credential with a particular time-restricted lifespan may implement this interface to allow callers to refresh the time period for which it is valid. The interface has two abstract methods:boolean isCurrent();This method determines whether the credential is current or valid.void refresh() throws RefreshFailedException;This method updates or extends the validity of the credential. The method implementation should perform anAuthPermission("refreshCredential")security check to ensure the caller has permission to refresh the credential.Destroyable
The
javax.security.auth.Destroyableinterface provides the capability of destroying the contents within a credential. The interface has two abstract methods:boolean isDestroyed();Determines whether the credential has been destroyed.void destroy() throws DestroyFailedException;Destroys and clears the information associated with this credential. Subsequent calls to certain methods on this credential will result in anIllegalStateExceptionbeing thrown. The method implementation should perform anAuthPermission("destroyCredential")security check to ensure the caller has permission to destroy the credential.Authentication Classes and Interfaces
To authenticate a subject (user or service), the following steps are performed:
- An application instantiates a
LoginContext.- The
LoginContextconsults aConfigurationto load all of theLoginModules configured for that application.- The application invokes the
LoginContext'sloginmethod.- The
loginmethod invokes all of the loadedLoginModules. EachLoginModuleattempts to authenticate the subject. Upon success,LoginModules associate relevantPrincipals and credentials with aSubjectobject that represents the subject being authenticated.- The
LoginContextreturns the authentication status to the application.- If authentication succeeded, the application retrieves the
Subjectfrom theLoginContext.The authentication classes are described below.
LoginContext
The
javax.security.auth.login.LoginContextclass provides the basic methods used to authenticate subjects, and provides a way to develop an application independent of the underlying authentication technology. TheLoginContextconsults aConfigurationto determine the authentication services, orLoginModule(s), configured for a particular application. Therefore, differentLoginModules can be plugged in under an application without requiring any modifications to the application itself.
LoginContextoffers four constructors from which to choose:public LoginContext(String name) throws LoginException; public LoginContext(String name, Subject subject) throws LoginException; public LoginContext(String name, CallbackHandler callbackHandler) throws LoginException public LoginContext(String name, Subject subject, CallbackHandler callbackHandler) throws LoginExceptionAll of the constructors share a common parameter:name. This argument is used by theLoginContextas an index into the login Configuration to determine whichLoginModules are configured for the application instantiating theLoginContext. Constructors that do not take aSubjectas an input parameter instantiate a newSubject. Null inputs are disallowed for all constructors. Callers require anAuthPermissionwith target "createLoginContext.<name>" to instantiate aLoginContext. Here, <name> refers to the name of the login configuration entry that the application references in thenameparameter for theLoginContextinstantiation.See the CallbackHandler section for information on what a
CallbackHandleris and when you may need one.Actual authentication occurs with a call to the following method:
public void login() throws LoginException;When
loginis invoked, all of the configuredLoginModules are invoked to perform the authentication. If the authentication succeeded, theSubject(which may now holdPrincipals, public credentials, and private credentials) can be retrieved by using the following method:public Subject getSubject();To logout a
Subjectand remove its authenticatedPrincipalsand credentials, the following method is provided:public void logout() throws LoginException;The following code sample demonstrates the calls necessary to authenticate and logout a Subject:
// let the LoginContext instantiate a new Subject LoginContext lc = new LoginContext("entryFoo"); try { // authenticate the Subject lc.login(); System.out.println("authentication successful"); // get the authenticated Subject Subject subject = lc.getSubject(); ... // all finished -- logout lc.logout(); } catch (LoginException le) { System.err.println("authentication unsuccessful: " + le.getMessage()); }LoginModule
The
LoginModuleinterface gives developers the ability to implement different kinds of authentication technologies that can be plugged in under an application. For example, one type ofLoginModulemay perform a username/password-based form of authentication. OtherLoginModules may interface to hardware devices such as smart cards or biometric devices.Note: If you are an application writer, you do not need to understand the workings of
LoginModules. All you have to know is how to write your application and specify configuration information (such as in a login configuration file) such that the application will be able to utilize the LoginModule specified by the configuration to authenticate the user.If, on the other hand, you are a programmer who wishes to write a LoginModule implementing an authentication technology, see the JAAS
LoginModuleDeveloper's Guide for detailed step-by-step instructions.CallbackHandler
In some cases a
LoginModulemust communicate with the user to obtain authentication information.LoginModules use a javax.security.auth.callback.CallbackHandler for this purpose. Applications implement theCallbackHandlerinterface and pass it to theLoginContext, which forwards it directly to the underlyingLoginModules. ALoginModuleuses theCallbackHandlerboth to gather input from users (such as a password or smart card pin number) or to supply information to users (such as status information). By allowing the application to specify theCallbackHandler, underlyingLoginModulescan remain independent of the different ways applications interact with users. For example, the implementation of aCallbackHandlerfor a GUI application might display a window to solicit input from a user. On the other hand, the implementation of aCallbackHandlerfor a non-GUI tool might simply prompt the user for input directly from the command line.CallbackHandleris an interface with one method to implement:void handle(Callback[] callbacks) throws java.io.IOException, UnsupportedCallbackException;The
LoginModulepasses theCallbackHandler handlemethod an array of appropriateCallbacks, for example a NameCallback for the user name and a PasswordCallback for the password, and theCallbackHandlerperforms the requested user interaction and sets appropriate values in theCallbacks. For example, to process aNameCallback, theCallbackHandlermay prompt for a name, retrieve the value from the user, and call theNameCallback'ssetNamemethod to store the name.The
CallbackHandlerdocumentation has a lengthy example not included in this document that readers may want to examine.Callback
The javax.security.auth.callback package contains theCallbackinterface as well as several implementations.LoginModules may pass an array ofCallbacks directly to thehandlemethod of a CallbackHandler.Please consult the various
CallbackAPIs for more information on their use.Authorization Classes
To make JAAS authorization take place, granting access control permissions based not just on what code is running but also on who is running it, the following is required:
- The user must be authenticated, as described in the LoginContext section.
- The Subject that is the result of authentication must be associated with an access control context, as described in the Subject section.
- Principal-based entries must be configured in the security policy, as described below.
The
Policyabstract class and the authorization-specific classesAuthPermissionandPrivateCredentialPermissionare described below.Policy
The
java.security.Policyclass is an abstract class for representing the system-wide access control policy. ThePolicyAPI was upgraded in the J2SDK 1.4 to supportPrincipal-based queries.As a default, the J2SDK provides a file-based subclass implementation, which was upgraded to support
Principal-basedgrantentries in policy files.Policy files and the structure of entries within them are described in Default Policy Implementation and Policy File Syntax.
AuthPermission
The
javax.security.auth.AuthPermissionclass encapsulates the basic permissions required for JAAS. AnAuthPermissioncontains a name (also referred to as a "target name") but no actions list; you either have the named permission or you don't.In addition to its inherited methods (from the
java.security.Permissionclass), anAuthPermissionhas two public constructors:public AuthPermission(String name); public AuthPermission(String name, String actions);The first constructor creates a newAuthPermissionwith the specified name. The second constructor also creates a newAuthPermissionobject with the specified name, but has an additionalactionsargument which is currently unused and should be null. This constructor exists solely for thePolicyobject to instantiate newPermissionobjects. For most other code, the first constructor is appropriate.Currently the
AuthPermissionobject is used to guard access to thePolicy,Subject,LoginContext, andConfigurationobjects. Please refer to the AuthPermission javadocs for the list of valid names that are supported.PrivateCredentialPermission
The
javax.security.auth.PrivateCredentialPermissionclass protects access to aSubject's private credentials and provides one public constructor:public PrivateCredentialPermission(String name, String actions);Please refer to the PrivateCredentialPermission javadocs for more detailed information on this class.
JAAS Tutorials and Sample Programs
The JAAS Authentication and JAAS Authorization tutorials contain the following samples:
- SampleAcn.java is a sample application demonstrating JAAS authentication.
- SampleAzn.java is a sample application used by the authorization tutorial. It demonstrates both authentication and authorization.
- sample_jaas.config is a sample login configuration file used by both tutorials.
- sampleacn.policy is a sample policy file granting permissions required by the code for the authentication tutorial.
- sampleazn.policy is a sample policy file granting permissions required by the code for the authorization tutorial.
- SampleLoginModule.java is the class specified by the tutorials' login configuration file (
sample_jaas.config) as the class implementing the desired underlying authentication. SampleLoginModule's user authentication consists of simply verifying that the name and password specified by the user have specific values.- SamplePrincipal.java is a sample class implementing the
Principalinterface. It is used by SampleLoginModule.See the tutorials for detailed information about the applications, the policy files, and the login configuration file.
Application writers do not need to understand the code for SampleLoginModule.java or SamplePrincipal.java, as explained in the tutorials. Programmers who wish to write LoginModules can learn how to do so by reading the JAAS LoginModule Developer's Guide.
Appendix A: JAAS Settings in the java.security Security Properties File
A number of JAAS-related settings can be configured in the
java.securitymaster security properties file, which is located in the lib/security directory of the Java runtime.JAAS adds two new security properties to
java.security:
login.configuration.providerlogin.config.url.nThe following pre-existing properties are also relevant for JAAS users:
policy.providerpolicy.url.nLogin Configuration Provider
The default JAAS login configuration implementation provided by Sun Microsystems gets its configuration information from files and expects the information to be provided in a specific format shown in the tutorials.
The default JAAS login configuration implementation can be replaced by specifying the alternative provider class implementation in the
login.configuration.providerproperty.For example:
login.configuration.provider=com.foo.ConfigIf the Security propertylogin.configuration.provideris not found, or is left unspecified, then it is set to the default value:login.configuration.provider=com.sun.security.auth.login.ConfigFileNote that there is no means to dynamically set the login configuration provider from the command line.
Login Configuration URLs
If you are using a login configuration implementation that expects the configuration information to be specified in files (as does the default implementation from Sun Microsystems), the location of the login configuration file(s) can be statically set by specifying their respective URLs in the
login.config.url.nproperty. 'n' is a consecutively numbered integer starting with 1. If multiple configuration files are specified (if n >= 2), they will be read and unioned into one single configuration.For example:
login.config.url.1=file:C:/config/.java.login.config login.config.url.2=file:C:/users/foo/.foo.login.configIf the location of the configuration files is not set in the
java.securityproperties file, and also is not specified dynamically from the command line (via the-Djava.security.auth.login.configoption), JAAS attempts to load a default configuration fromfile:${user.home}/.java.login.configPolicy Provider
The default policy implementation can be replaced by specifying the alternative provider class implementation in the
policy.providerproperty.For example:
policy.provider=com.foo.PolicyIf the Security propertypolicy.provideris not found, or is left unspecified, then thePolicyis set to the default value:policy.provider=sun.security.provider.PolicyFileNote that there is no means to dynamically set the policy provider from the command line.
Policy File URLs
The location of the access control policy files can be statically set by specifying their respective URLs in the
auth.policy.url.nproperty. 'n' is a consecutively numbered integer starting with 1. If multiple policies are specified (if n >= 2), they will be read and unioned into one single policy.For example:
policy.url.1=file:C:/policy/.java.policy policy.url.2=file:C:/users/foo/.foo.policyIf the location of the policy file(s) is not set in the
java.securityproperties file, and is not specified dynamically from the command line (via the-Djava.security.policyoption), the access control policy defaults to the same policy as that of the system policy file installed with the the J2SDK. That policy file
- grants all permissions to standard extensions
- allows anyone to listen on un-privileged ports
- allows any code to read certain "standard" properties that are not security-sensitive, such as the "os.name" and "file.separator" properties.
Sample Master Security Properties File
Below is a modified copy of the
java.securityfile provided with the Java SE 6. Example settings for JAAS-related properties are shown in bold. In this example, we leave the values provided in the defaultjava.securityfile for thepolicy.provider,policy.url.n, andlogin.configuration.providerproperties. The defaultjava.securityfile also lists a value for thelogin.config.url.nproperty, but it is commented out. In the example below, it is not commented.# # This is the "master security properties file". # # In this file, various security properties are set for use by # java.security classes. This is where users can statically register # Cryptography Package Providers ("providers" for short). The term # "provider" refers to a package or set of packages that supply a # concrete implementation of a subset of the cryptography aspects of # the Java Security API. A provider may, for example, implement one or # more digital signature algorithms or message digest algorithms. # # Each provider must implement a subclass of the Provider class. # To register a provider in this master security properties file, # specify the Provider subclass name and priority in the format # # security.provider.<n>=<className> # # This declares a provider, and specifies its preference # order <n>. The preference order is the order in which providers are # searched for requested algorithms (when no specific provider is # requested). The order is 1-based; 1 is the most preferred, followed # by 2, and so on. # # <className> must specify the subclass of the Provider class whose # constructor sets the values of various properties that are required # for the Java Security API to look up the algorithms or other # facilities implemented by the provider. # # There must be at least one provider specification in java.security. # There is a default provider that comes standard with the JDK. It # is called the "SUN" provider, and its Provider subclass # named Sun appears in the sun.security.provider package. Thus, the # "SUN" provider is registered via the following: # # security.provider.1=sun.security.provider.Sun # # (The number 1 is used for the default provider.) # # Note: Statically registered Provider subclasses are instantiated # when the system is initialized. Providers can be dynamically # registered instead by calls to either the addProvider or # insertProviderAt method in the Security class. # # List of providers and their preference orders (see above): # security.provider.1=sun.security.provider.Sun security.provider.2=com.sun.net.ssl.internal.ssl.Provider security.provider.3=com.sun.rsajca.Provider security.provider.4=com.sun.crypto.provider.SunJCE security.provider.5=sun.security.jgss.SunProvider # # Select the source of seed data for SecureRandom. By default it uses # a system/thread activity algorithm. Optionally, if the platform supports # it an entropy gathering device can be selected. # #securerandom.source=file:/dev/random # # The entropy gathering device is described as a URL and can # also be specified with the property "java.security.egd". For example, # -Djava.security.egd=file:/dev/urandom # Specifying this property will override the securerandom.source setting. # # Class to instantiate as the javax.security.auth.login.Configuration # provider. # login.configuration.provider=com.sun.security.auth.login.ConfigFile # # Default login configuration file # login.config.url.1=file:${user.home}/.java.login.config # # Class to instantiate as the system Policy. This is the name of the class # that will be used as the Policy object. # policy.provider=sun.security.provider.PolicyFile # The default is to have a single system-wide policy file, # and a policy file in the user's home directory. policy.url.1=file:${java.home}/lib/security/java.policy policy.url.2=file:${user.home}/.java.policy # whether or not we expand properties in the policy file # if this is set to false, properties (${...}) will not be expanded in policy # files. policy.expandProperties=true # whether or not we allow an extra policy to be passed on the command line # with -Djava.security.policy=somefile. Comment out this line to disable # this feature. policy.allowSystemProperty=true # whether or not we look into the IdentityScope for trusted Identities # when encountering a 1.1 signed JAR file. If the identity is found # and is trusted, we grant it AllPermission. policy.ignoreIdentityScope=false # # Default keystore type. # keystore.type=jks # # Class to instantiate as the system scope: # system.scope=sun.security.provider.IdentityDatabase # # List of comma-separated packages that start with or equal this string # will cause a security exception to be thrown when # passed to checkPackageAccess unless the # corresponding RuntimePermission ("accessClassInPackage."+package) has # been granted. package.access=sun. # # List of comma-separated packages that start with or equal this string # will cause a security exception to be thrown when # passed to checkPackageDefinition unless the # corresponding RuntimePermission ("defineClassInPackage."+package) has # been granted. # # by default, no packages are restricted for definition, and none of # the class loaders supplied with the JDK call checkPackageDefinition. # #package.definition= # # Determines whether this properties file can be appended to # or overridden on the command line via -Djava.security.properties # security.overridePropertiesFile=true # # Determines the default key and trust manager factory algorithms for # the javax.net.ssl package. # ssl.KeyManagerFactory.algorithm=SunX509 ssl.TrustManagerFactory.algorithm=SunX509 # # Determines the default SSLSocketFactory and SSLServerSocketFactory # provider implementations for the javax.net.ssl package. If, due to # export and/or import regulations, the providers are not allowed to be # replaced, changing these values will produce non-functional # SocketFactory or ServerSocketFactory implementations. # #ssl.SocketFactory.provider= #ssl.ServerSocketFactory.provider=
Login configurations are located using the
login.config.url.nsecurity properties found in thejava.securityfile. For more information about this property and the location of thejava.securityfile, see Appendix A.The default Configuration implementation,
ConfigFile, gets its configuration information from login configuration files. For details about the default login Configuration implementation provided with JAAS, please consult the javadocs for thecom.sun.security.auth.login.ConfigFileclass.The following is a sample login configuration file.
Login1 { sample.SampleLoginModule required debug=true; }; Login2 { sample.SampleLoginModule required; com.sun.security.auth.module.NTLoginModule sufficient; com.foo.SmartCard requisite debug=true; com.foo.Kerberos optional debug=true; };The application Login1 only has one configured LoginModule,
SampleLoginModule. Therefore, an attempt by Login1 to authenticate a subject (user or service) will be successful if and only if theSampleLoginModulesucceeds.The authentication logic for the application Login2 is easier to explain with the table below. Note: the
required,sufficient,requisite, andoptionalflags are described in theConfigurationjavadocs.* = trivial value due to control returning to the application because a previous requisite module failed or a previous sufficient module succeeded.
Login2 Authentication Status SampleLoginModule required pass pass pass pass fail fail fail fail NTLoginModule sufficient pass fail fail fail pass fail fail fail SmartCard requisite * pass pass fail * pass pass fail Kerberos optional * pass fail * * pass fail * Overall Authentication pass pass pass fail fail fail fail fail
Copyright © 1993, 2010, Oracle and/or its affiliates. All rights reserved. Please send comments using this Feedback page. |
Java Technology |