Chapter 17. The java.security PackageThe java.security package contains the classes and interfaces that implement the Java security architecture. These classes can be divided into two broad categories. First, there are classes that implement access control and prevent untrusted code from performing sensitive operations. Second, there are authentication classes that implement message digests and digital signatures and can authenticate Java classes and other objects. The central access control class is AccessController; it uses the currently installed Policy object to decide whether a given class has Permission to access a given system resource. The Permissions and ProtectionDomain classes are also important pieces of the Java access control architecture. Figure 17-1 shows the access control classes of this package. Figure 17-1. The access control classes of the java.security packageThe key classes for authentication are MessageDigest and Signature; they compute and verify cryptographic message digests and digital signatures. These classes use public-key cryptography techniques and rely on the PublicKey and PrivateKey classes. They also rely on an infrastructure of related classes, such as SecureRandom for producing cryptographic-strength pseudo-random numbers, KeyPairGenerator for generating pairs of public and private keys, and KeyStore for managing a collection of keys and certificates. (This package defines a Certificate interface, but it is deprecated; see the java.security.cert package for the preferred Certificate class.) Figure 17-2 shows the authentication classes of java.security, while Figure 17-3 shows the exceptions. Figure 17-2. The authentication classes of the java.security packageFigure 17-3. The exception classes of the java.security packageThe CodeSource class unites the authentication classes with the access control classes. It represents the source of a Java class as a URL and a set of java.security.cert.Certificate objects that contain the digital signatures of the code. The AccessController and Policy classes look at the CodeSource of a class when making access control decisions. All the cryptographic-authentication features of this package are provider-based, which means they are implemented by security provider modules that can be plugged easily into any Java 1.2 (or later) installation. Thus, in addition to defining a security API, this package also defines a service provider interface (SPI). Various classes with names that end in "Spi" are part of this SPI. Security provider implementations must subclass these Spi classes, but applications never need to use them. Each security provider is represented by a Provider class, and the Security class allows new providers to be dynamically installed. The java.security package contains several useful utility classes. For example, DigestInputStream and DigestOutputStream make it easy to compute message digests. GuardedObject provides customizable access control for an individual object. SignedObject protects the integrity of an arbitrary Java object by attaching a digital signature, making it easy to detect any tampering with the object. Although the java.security package contains cryptographic classes for authentication, it does not contain classes for encryption or decryption. U.S. export control laws prevent Sun from including encryption and decryption functionality in the core Java platform. Instead, this functionality is part of the Java Cryptography Extension, or JCE. The JCE builds upon the cryptographic infrastructure of java.security; see Chapter 26, "The javax.crypto Package".
This class encapsulates the state of a call stack. The checkPermission() method can make access-control decisions based on the saved state of the call stack. Access-control checks are usually performed by the AccessController.checkPermission() method, which checks that the current call stack has the required permissions. Sometimes, however, it is necessary to make access-control decisions based on a previous state of the call stack. Call AccessController.getContext() to create an AccessControlContext for a particular call stack. In Java 1.3, this class has constructors that specify a custom context in the form of an array of ProtectionDomain objects and that associate a DomainCombiner object with an existing AccessControlContext. This class is used only by system-level code; typical applications rarely need to use it.
Passed To: AccessControlContext.AccessControlContext(), AccessController.doPrivileged() Returned By: AccessController.getContext()
Thrown by AccessController to signal that an access request has been denied. getPermission() returns the Permission object, if any, that was involved in the denied request.
Hierarchy: Object-->Throwable(Serializable)-->Exception-->RuntimeException-->SecurityException-->AccessControlException Thrown By: AccessControlContext.checkPermission(), AccessController.checkPermission()
The static methods of this class implement the default access-control mechanism as of Java 1.2. checkPermission() traverses the call stack of the current thread and checks whether all classes in the call stack have the requested permission. If so, checkPermission() returns, and the operation can proceed. If not, checkPermission() throws an AccessControlException. As of Java 1.2, the checkPermission() method of the default java.lang.SecurityManager calls AccessController.checkPermission(). System-level code that needs to perform an access check should invoke the SecurityManager method rather than calling the AccessController method directly. Unless you are writing system-level code that must control access to system resources, you never need to use this class or the SecurityManager.checkPermission() method. The various doPrivileged() methods run blocks of privileged code encapsulated in a PrivilegedAction or PrivilegedExceptionAction object. When checkPermission() is traversing the call stack of a thread, it stops if it reaches a privileged block that was executed with doPrivileged(). This means that privileged code can run with a full set of privileges, even if it was invoked by untrusted or lower-privileged code. See PrivilegedAction for more details. The getContext() method returns an AccessControlContext that represents the current security context of the caller. Such a context might be saved and passed to a future call (perhaps a call made from a different thread). Use the two-argument version of doPrivileged() to force permission checks to check the AccessControlContext as well.
This class defines a generic API for generating parameters for a cryptographic algorithm, typically a Signature or a javax.crypto.Cipher. Create an AlgorithmParameterGenerator by calling one of the static getInstance() factory methods and specifying the name of the algorithm and, optionally, the name of the desired provider. The default "SUN" provider supports the "DSA" algorithm. The "SunJCE" provider shipped with the JCE supports "DiffieHellman". Once you have obtained a generator, initialize it by calling the init() method and specifying an algorithm-independent parameter size (in bits) or an algorithm-dependent AlgorithmParameterSpec object. You may also specify a SecureRandom source of randomness when you call init(). Once you have created and initialized the AlgorithmParameterGenerator, call generateParameters() to generate an AlgorithmParameters object.
Returned By: AlgorithmParameterGenerator.getInstance()
This abstract class defines the service-provider interface for algorithm-parameter generation. A security provider must implement a concrete subclass of this class for each algorithm it supports. Applications never need to use or subclass this class.
Passed To: AlgorithmParameterGenerator.AlgorithmParameterGenerator()
This class is a generic, opaque representation of the parameters used by some cryptographic algorithm. You can create an instance of the class with one of the static getInstance() factory methods, specifying the desired algorithm and, optionally, the desired provider. The default "SUN" provider supports the "DSA" algorithm. The "SunJCE" provider shipped with the JCE supports "DES", "DESede", "PBE", "Blowfish", and "DiffieHellman". Once you have obtained an AlgorithmParameters object, initialize it by passing an algorithm-specific java.security.spec.AlgorithmParameterSpec object or the encoded parameter values as a byte array to the init() method. You can also create an AlgorithmParameters object with an AlgorithmParameterGenerator. getEncoded() returns the initialized algorithm parameters as a byte array, using either the algorithm-specific default encoding or the named encoding format you specified.
Passed To: javax.crypto.Cipher.init(), javax.crypto.CipherSpi.engineInit() Returned By: AlgorithmParameterGenerator.generateParameters(), AlgorithmParameterGeneratorSpi.engineGenerateParameters(), AlgorithmParameters.getInstance(), javax.crypto.Cipher.getParameters(), javax.crypto.CipherSpi.engineGetParameters()
This abstract class defines the service-provider interface for AlgorithmParameters. A security provider must implement a concrete subclass of this class for each cryptographic algorithm it supports. Applications never need to use or subclass this class.
Passed To: AlgorithmParameters.AlgorithmParameters()
This class is a Permission subclass whose implies() method always returns true. This means that code that has been granted AllPermission is granted all other possible permissions. This class exists to provide a convenient way to grant all permissions to completely trusted code. It should be used with care. Applications typically do not need to work directly with Permission objects.
Hierarchy: Object-->java.security.Permission(Guard,Serializable)-->AllPermission
This Permission class is the abstract superclass for a number of simple permission types. BasicPermission is typically subclassed to implement named permissions that have a name, or target, string, but do not support actions. The implies() method of BasicPermission defines a simple wildcarding capability. The target "*" implies permission for any target. The target "x.*" implies permission for any target that begins with "x.". Applications typically do not need to work directly with Permission objects.
Hierarchy: Object-->java.security.Permission(Guard,Serializable)-->BasicPermission(Serializable) Subclasses: java.awt.AWTPermission, java.io.SerializablePermission, RuntimePermission, java.lang.reflect.ReflectPermission, java.net.NetPermission, SecurityPermission, java.sql.SQLPermission, java.util.PropertyPermission
This interface was used in Java 1.1 to represent an identity certificate. It has been deprecated as of Java 1.2 in favor of the java.security.cert package (see Chapter 19, The java.security.cert Package.) See also java.security.cert.Certificate.
Passed To: Identity.{addCertificate(), removeCertificate()} Returned By: Identity.certificates()
This class represents the source of a Java class, as defined by the URL from which the class was loaded and the set of digital signatures attached to the class. A CodeSource object is created by specifying a java.net.URL and an array of java.security.cert.Certificate objects. Only applications that create custom ClassLoader objects should ever need to use or subclass this class. When a CodeSource represents a specific piece of Java code, it includes a fully qualified URL and the actual set of certificates used to sign the code. When a CodeSource object defines a ProtectionDomain, however, the URL may include wildcards, and the array of certificates is a minimum required set of signatures. The implies() method of such a CodeSource tests whether a particular Java class comes from a matching URL and has the required set of signatures.
Hierarchy: Object-->CodeSource(Serializable) Passed To: java.net.URLClassLoader.getPermissions(), CodeSource.implies(), java.security.Policy.getPermissions(), ProtectionDomain.ProtectionDomain(), SecureClassLoader.{defineClass(), getPermissions()} Returned By: ProtectionDomain.getCodeSource()
Signals a problem creating a message digest.
Hierarchy: Object-->Throwable(Serializable)-->Exception-->GeneralSecurityException-->DigestException Thrown By: MessageDigest.digest(), MessageDigestSpi.engineDigest()
This class is a byte input stream with an associated MessageDigest object. When bytes are read with any of the read() methods, those bytes are automatically passed to the update() method of the MessageDigest. When you have finished reading bytes, you can call the digest() method of the MessageDigest to obtain a message digest. If you want to compute a digest just for some of the bytes read from the stream, use on() to turn the digesting function on and off. Digesting is on by default; call on(false) to turn it off. See also DigestOutputStream and MessageDigest.
Hierarchy: Object-->java.io.InputStream-->java.io.FilterInputStream-->DigestInputStream
This class is a byte output stream with an associated MessageDigest object. When bytes are written to the stream with any of the write() methods, those bytes are automatically passed to the update() method of the MessageDigest. When you have finished writing bytes, you can call the digest() method of the MessageDigest to obtain a message digest. If you want to compute a digest just for some of the bytes written to the stream, use on() to turn the digesting function on and off. Digesting is on by default; call on(false) to turn it off. See also DigestInputStream and MessageDigest.
Hierarchy: Object-->java.io.OutputStream-->java.io.FilterOutputStream-->DigestOutputStream
This interface defines a single combine() method that combines two arrays of ProtectionDomain objects into a single equivalent (and perhaps optimized) array. You can associate a DomainCombiner with an existing AccessControlContext by calling the two-argument AccessControlContext() constructor. Then, when the checkPermission() method of the AccessControlContext is called or when the AccessControlContext is passed to a doPrivileged() method of AccessController, the specified DomainCombiner merges the protection domains of the current stack frame with the protection domains encapsulated in the AccessControlContext. This class is used only by system-level code; typical applications rarely need to use it.
Passed To: AccessControlContext.AccessControlContext() Returned By: AccessControlContext.getDomainCombiner()
This class is the superclass of most of the exceptions defined by the java.security package.
Hierarchy: Object-->Throwable(Serializable)-->Exception-->GeneralSecurityException Subclasses: DigestException, InvalidAlgorithmParameterException, KeyException, KeyStoreException, NoSuchAlgorithmException, NoSuchProviderException, SignatureException, UnrecoverableKeyException, java.security.cert.CertificateException, java.security.cert.CRLException, java.security.spec.InvalidKeySpecException, java.security.spec.InvalidParameterSpecException, javax.crypto.BadPaddingException, javax.crypto.IllegalBlockSizeException, javax.crypto.NoSuchPaddingException, javax.crypto.ShortBufferException
This interface guards access to an object. The checkGuard() method is passed an object to which access has been requested. If access should be granted, checkGuard() should return silently. Otherwise, if access is denied, checkGuard() should throw a java.lang.SecurityException. The Guard object is used primarily by the GuardedObject class. Note that all Permission objects implement the Guard interface.
Implementations: java.security.Permission Passed To: GuardedObject.GuardedObject()
This class uses a Guard object to guard against unauthorized access to an arbitrary encapsulated object. Create a GuardedObject by specifying an object and a Guard for it. The getObject() method calls the checkGuard() method of the Guard to determine whether access to the object should be allowed. If access is allowed, getObject() returns the encapsulated object. Otherwise, it throws a java.lang.SecurityException. The Guard object used by a GuardedObject is often a Permission. In this case, access to the guarded object is granted only if the calling code is granted the specified permission by the current security policy.
Hierarchy: Object-->GuardedObject(Serializable)
This deprecated class was used in Java 1.1 to represent an entity or Principal with an associated PublicKey object. In Java 1.1, the public key for a named entity could be retrieved from the system keystore with a line like the following: IdentityScope.getSystemScope().getIdentity(name).getPublicKey() As of Java 1.2, the Identity class and the related IdentityScope and Signer classes have been deprecated in favor of KeyStore and java.security.cert.Certificate.
Hierarchy: Object-->Identity(java.security.Principal,Serializable) Subclasses: IdentityScope, Signer Passed To: Identity.identityEquals(), IdentityScope.{addIdentity(), removeIdentity()}, javax.ejb.EJBContext.isCallerInRole(), javax.ejb.deployment.AccessControlEntry.{AccessControlEntry(), setAllowedIdentities()}, javax.ejb.deployment.ControlDescriptor.setRunAsIdentity() Returned By: IdentityScope.getIdentity(), javax.ejb.EJBContext.getCallerIdentity(), javax.ejb.deployment.AccessControlEntry.getAllowedIdentities(), javax.ejb.deployment.ControlDescriptor.getRunAsIdentity()
This deprecated class was used in Java 1.1 to represent a group of Identity and Signer objects and their associated PublicKey and PrivateKey objects. As of Java 1.2, it has been replaced by the KeyStore class.
Hierarchy: Object-->Identity(java.security.Principal,Serializable)-->IdentityScope Passed To: Identity.Identity(), IdentityScope.{IdentityScope(), setSystemScope()}, Signer.Signer() Returned By: Identity.getScope(), IdentityScope.getSystemScope()
Signals that one or more algorithm parameters (usually specified by a java.security.spec.AlgorithmParameterSpec object) are not valid.
Hierarchy: Object-->Throwable(Serializable)-->Exception-->GeneralSecurityException-->InvalidAlgorithmParameterException Thrown By: Too many methods to list.
Signals that a Key is not valid.
Hierarchy: Object-->Throwable(Serializable)-->Exception-->GeneralSecurityException-->KeyException-->InvalidKeyException Thrown By: Too many methods to list.
This subclass of java.lang.IllegalArgumentException signals that a parameter passed to a security method is not valid. This exception type is not widely used.
Hierarchy: Object-->Throwable(Serializable)-->Exception-->RuntimeException-->IllegalArgumentException-->InvalidParameterException Thrown By: Signature.{getParameter(), setParameter()}, SignatureSpi.{engineGetParameter(), engineSetParameter()}, Signer.setKeyPair(), java.security.interfaces.DSAKeyPairGenerator.initialize()
This interface defines the high-level characteristics of all cryptographic keys. getAlgorithm() returns the name of the cryptographic algorithm (such as RSA) used with the key. getFormat() return the name of the external encoding (such as X.509) used with the key. getEncoded() returns the key as an array of bytes, encoded using the format specified by getFormat().
Hierarchy: (Key(Serializable)) Implementations: PrivateKey, PublicKey, javax.crypto.SecretKey Passed To: Too many methods to list. Returned By: KeyFactory.translateKey(), KeyFactorySpi.engineTranslateKey(), KeyStore.getKey(), KeyStoreSpi.engineGetKey(), javax.crypto.KeyAgreement.doPhase(), javax.crypto.KeyAgreementSpi.engineDoPhase()
Signals that something is wrong with a key. See also the subclasses InvalidKeyException and KeyManagementException.
Hierarchy: Object-->Throwable(Serializable)-->Exception-->GeneralSecurityException-->KeyException Subclasses: InvalidKeyException, KeyManagementException Thrown By: java.security.Certificate.{decode(), encode()}, Signer.setKeyPair()
This class translates asymmetric cryptographic keys between the two representations used by the Java Security API. java.security.Key is the opaque, algorithm-independent representation of a key used by most of the Security API. java.security.spec.KeySpec is a marker interface implemented by transparent, algorithm-specific representations of keys. KeyFactory is used with public and private keys; see javax.crypto.SecretKeyFactory if you are working with symmetric or secret keys. To convert a Key to a KeySpec or vice versa, create a KeyFactory by calling one of the static getInstance() factory methods and specifying the name of the key algorithm (e.g., DSA or RSA). Then, use generatePublic() or generatePrivate() to create a PublicKey or PrivateKey object from a corresponding KeySpec. Or use getKeySpec() to obtain a KeySpec for a given Key. Because there can be more than one KeySpec implementation used by a particular cryptographic algorithm, you must also specify the Class of the KeySpec you desire. If you do not need to transport keys portably between applications and/or systems, you can use a KeyStore to store and retrieve keys and certificates, avoiding KeySpec and KeyFactory altogether.
Returned By: KeyFactory.getInstance()
This abstract class defines the service-provider interface for KeyFactory. A security provider must implement a concrete subclass of this class for each cryptographic algorithm it supports. Applications never need to use or subclass this class.
Passed To: KeyFactory.KeyFactory()
Signals an exception in a key management operation. In Java 1.2, this exception is only thrown by deprecated methods.
Hierarchy: Object-->Throwable(Serializable)-->Exception-->GeneralSecurityException-->KeyException-->KeyManagementException Thrown By: Identity.{addCertificate(), Identity(), removeCertificate(), setPublicKey()}, IdentityScope.{addIdentity(), IdentityScope(), removeIdentity()}, Signer.Signer()
This class is a simple container for a PublicKey and a PrivateKey object. Because a KeyPair contains an unprotected private key, it must be used with as much caution as a PrivateKey object.
Hierarchy: Object-->KeyPair(Serializable) Passed To: Signer.setKeyPair() Returned By: KeyPairGenerator.{generateKeyPair(), genKeyPair()}, KeyPairGeneratorSpi.generateKeyPair()
This class generates a public/private key pair for a specified cryptographic algorithm. To create a KeyPairGenerator, call one of the static getInstance() methods, specifying the name of the algorithm and, optionally, the name of the security provider to use. The default "SUN" provider shipped with Java 1.2 supports only the "DSA" algorithm. The "SunJCE" provider of the Java Cryptography Extension (JCE) additionally supports the "DiffieHellman" algorithm. Once you have created a KeyPairGenerator, initialize it by calling initialize(). You can perform an algorithm-independent initialization by simply specifying the desired key size in bits. Alternatively, you can do an algorithm-dependent initialization by providing an appropriate AlgorithmParameterSpec object for the key-generation algorithm. In either case, you may optionally provide your own source of randomness in the guise of a SecureRandom object. Once you have created and initialized a KeyPairGenerator, call genKeyPair() to create a KeyPair object. Remember that the KeyPair contains a PrivateKey that must be kept private. For historical reasons, KeyPairGenerator extends KeyPairGeneratorSpi. Applications should not use any methods inherited from that class.
Hierarchy: Object-->KeyPairGeneratorSpi-->KeyPairGenerator Returned By: KeyPairGenerator.getInstance()
This abstract class defines the service-provider interface for KeyPairGenerator. A security provider must implement a concrete subclass of this class for each cryptographic algorithm for which it can generate key pairs. Applications never need to use or subclass this class.
Subclasses: KeyPairGenerator
This class represents a mapping of names, or aliases, to Key and java.security.cert.Certificate objects. Obtain a KeyStore object by calling one of the static getInstance() methods, specifying the desired key store type and, optionally, the desired provider. Use "JKS" to specify the "Java Key Store" type defined by Sun. Because of U.S. export regulations, this default KeyStore supports only weak encryption of private keys. If you have the Java Cryptography Extension installed, use the type "JCEKS" and provider "SunJCE" to obtain a KeyStore implementation that offers much stronger password-based encryption of keys. Once you have created a KeyStore, use load() to read its contents from a stream, supplying an optional password that verifies the integrity of the stream data. Keystores are typically read from a file named .keystore in the user's home directory. A KeyStore may contain both public and private key entries. A public key entry is represented by a Certificate object. Use getCertificate() to look up a named public key certificate and setCertificateEntry() to add a new public key certificate to the keystore. A private key entry in the keystore contains both a password-protected Key and an array of Certificate objects that represent the certificate chain for the public key that corresponds to the private key. Use getKey() and getCertificateChain() to look up the key and certificate chain. Use setKeyEntry() to create a new private key entry. You must provide a password when reading or writing a private key from the keystore; this password encrypts the key data, and each private key entry should have a different password. If you are using the JCE, you may also store javax.crypto.SecretKey objects in a KeyStore. Secret keys are stored like private keys, except that they do not have a certificate chain associated with them. To delete an entry from a KeyStore, use deleteEntry(). If you modify the contents of a KeyStore, use store() to save the keystore to a specified stream. You may specify a password that is used to validate the integrity of the data, but it is not used to encrypt the keystore.
Returned By: KeyStore.getInstance()
Signals a problem with a KeyStore.
Hierarchy: Object-->Throwable(Serializable)-->Exception-->GeneralSecurityException-->KeyStoreException Thrown By: Too many methods to list.
This abstract class defines the service-provider interface for KeyStore. A security provider must implement a concrete subclass of this class for each KeyStore type it supports. Applications never need to use or subclass this class.
Passed To: KeyStore.KeyStore()
This class computes a message digest (also known as a cryptographic checksum) for an arbitrary sequence of bytes. Obtain a MessageDigest object by calling one of the static getInstance() factory methods and specifying the desired algorithm (e.g., SHA or MD5) and, optionally, the desired provider. Next, specify the data to be digested by calling any of the update() methods one or more times. Finally, call digest(), which computes the message digest and returns it as an array of bytes. If you have only one array of bytes to be digested, you can pass it directly to digest() and skip the update() step. When you call digest(), the MessageDigest() object is reset and is then ready to compute a new digest. You can also explicitly reset a MessageDigest without computing the digest by calling reset(). To compute a digest for part of a message without resetting the MessageDigest, clone the MessageDigest and call digest() on the cloned copy. Note that not all implementations are cloneable, so the clone() method may throw an exception. The MessageDigest class is often used in conjunction with DigestInputStream and DigestOutputStream, which automate the update() calls for you.
Hierarchy: Object-->MessageDigestSpi-->MessageDigest Passed To: DigestInputStream.{DigestInputStream(), setMessageDigest()}, DigestOutputStream.{DigestOutputStream(), setMessageDigest()} Returned By: DigestInputStream.getMessageDigest(), DigestOutputStream.getMessageDigest(), MessageDigest.getInstance() Type Of: DigestInputStream.digest, DigestOutputStream.digest
This abstract class defines the service-provider interface for MessageDigest. A security provider must implement a concrete subclass of this class for each message-digest algorithm it supports. Applications never need to use or subclass this class.
Subclasses: MessageDigest
Signals that a requested cryptographic algorithm is not available. Thrown by getInstance() factory methods throughout the java.security package.
Hierarchy: Object-->Throwable(Serializable)-->Exception-->GeneralSecurityException-->NoSuchAlgorithmException Thrown By: Too many methods to list.
Signals that a requested cryptographic service provider is not available. Thrown by getInstance() factory methods throughout the java.security package.
Hierarchy: Object-->Throwable(Serializable)-->Exception-->GeneralSecurityException-->NoSuchProviderException Thrown By: Too many methods to list.
This abstract class represents a system resource, such as a file in the filesystem, or a system capability, such as the ability to accept network connections. Concrete subclasses of Permission, such as java.io.FilePermission and java.net.SocketPermission, represent specific types of resources. Permission objects are used by system code that is requesting access to a resource. They are also used by Policy objects that grant access to resources. The AccessController.checkPermission() method considers the source of the currently running Java code, determines the set of permissions that are granted to that code by the current Policy, and then checks to see whether a specified Permission object is included in that set. With the introduction of Java 1.2, this is the fundamental Java access-control mechanism. Each permission has a name (sometimes called the target) and, optionally, a comma-separated list of actions. For example, the name of a FilePermission is the name of the file or directory for which permission is being granted. The actions associated with this permission might be "read"; "write"; or "read,write". The interpretation of the name and action strings is entirely up to the implementation of Permission. A number of implementations support the use of wildcards; for example, a FilePermission can have a name of "/tmp/*", which represents access to any files in a /tmp directory. Permission objects must be immutable, so an implementation must never define a setName() or setActions() method. One of the most important abstract methods defined by Permission is implies(). This method must return true if this Permission implies another Permission. For example, if an application requests a FilePermission with name "/tmp/test" and action "read", and the current security Policy grants a FilePermission with name "/tmp/*" and actions "read,write", the request is granted because the requested permission is implied by the granted one. In general, only system-level code needs to work directly with Permission and its concrete subclasses. System administrators who are configuring security policies need to understand the various Permission subclasses. Applications that want to extend the Java access-control mechanism to provide customized access control to their own resources should subclass Permission to define custom permission types.
Hierarchy: Object-->java.security.Permission(Guard,Serializable) Subclasses: java.io.FilePermission, java.net.SocketPermission, AllPermission, BasicPermission, UnresolvedPermission Passed To: Too many methods to list. Returned By: java.net.HttpURLConnection.getPermission(), java.net.URLConnection.getPermission(), AccessControlException.getPermission()
This class is used by Permissions to store a collection of Permission objects that are all the same type. Like the Permission class itself, PermissionCollection defines an implies() method that can determine whether a requested Permission is implied by any of the Permission objects in the collection. Some Permission types may require a custom PermissionCollection type in order to correctly implement the implies() method. In this case, the Permission subclass should override newPermissionCollection() to return a Permission of the appropriate type. PermissionCollection is used by system code that manages security policies. Applications rarely need to use it.
Hierarchy: Object-->PermissionCollection(Serializable) Subclasses: Permissions Passed To: ProtectionDomain.ProtectionDomain() Returned By: java.io.FilePermission.newPermissionCollection(), java.net.SocketPermission.newPermissionCollection(), java.net.URLClassLoader.getPermissions(), AllPermission.newPermissionCollection(), BasicPermission.newPermissionCollection(), java.security.Permission.newPermissionCollection(), java.security.Policy.getPermissions(), ProtectionDomain.getPermissions(), SecureClassLoader.getPermissions(), UnresolvedPermission.newPermissionCollection(), java.util.PropertyPermission.newPermissionCollection()
This class stores an arbitrary collection of Permission objects. When Permission objects are added with the add() method, they are grouped into an internal set of PermissionCollection objects that contain only a single type of Permission. Use the elements() method to obtain an Enumeration of the Permission objects in the collection. Use implies() to determine if a specified Permission is implied by any of the Permission objects in the collection. Permissions is used by system code that manages security policies. Applications rarely need to use it.
Hierarchy: Object-->PermissionCollection(Serializable)-->Permissions(Serializable)
This class provides a mapping from CodeSource objects to PermissionCollection objects; it defines a security policy by specifying what permissions are granted to what code. There is only a single Policy in effect at any one time. Obtain the system policy by calling the static getPolicy() method. Code that has appropriate permissions can specify a new system policy by calling setPolicy(). getPermissions() is the central Policy method; it evaluates the Policy for a given CodeSource and returns an appropriate PermissionCollection. The refresh() method is a request to a Policy object to update its state (for example, by rereading its configuration file). The Policy class is used primarily by system-level code. Applications should not need to use this class unless they implement some kind of custom access-control mechanism.
Passed To: java.security.Policy.setPolicy() Returned By: java.security.Policy.getPolicy()
This interface represents any entity that may serve as a principal in a cryptographic transaction of any kind. A Principal may represent an individual, a computer, or an organization, for example.
Implementations: Identity, java.security.acl.Group Passed To: IdentityScope.getIdentity(), java.security.acl.Acl.{addEntry(), checkPermission(), getPermissions(), removeEntry(), setName()}, java.security.acl.AclEntry.setPrincipal(), java.security.acl.Group.{addMember(), isMember(), removeMember()}, java.security.acl.Owner.{addOwner(), deleteOwner(), isOwner()} Returned By: java.security.Certificate.{getGuarantor(), getPrincipal()}, java.security.acl.AclEntry.getPrincipal(), java.security.cert.X509Certificate.{getIssuerDN(), getSubjectDN()}, java.security.cert.X509CRL.getIssuerDN()
This interface represents a private cryptographic key. It extends the Key interface, but does not add any new methods. The interface exists in order to create a strong distinction between private and public keys. See also PublicKey.
Hierarchy: (PrivateKey(Key(Serializable))) Implementations: java.security.interfaces.DSAPrivateKey, java.security.interfaces.RSAPrivateKey, javax.crypto.interfaces.DHPrivateKey Passed To: KeyPair.KeyPair(), Signature.initSign(), SignatureSpi.engineInitSign(), SignedObject.SignedObject() Returned By: KeyFactory.generatePrivate(), KeyFactorySpi.engineGeneratePrivate(), KeyPair.getPrivate(), Signer.getPrivateKey()
This interface defines a block of code (the run() method) that is to be executed as privileged code by the AccessController.doPrivileged() method. When privileged code is run in this way, the AccessController looks only at the permissions of the immediate caller, not the permissions of the entire call stack. The immediate caller is typically fully trusted system code that has a full set of permissions, and therefore the privileged code runs with that full set of permissions, even if the system code is invoked by untrusted code with no permissions whatsoever. Privileged code is typically required only when you are writing a trusted system library (such as a Java extension package) that must read local files or perform other restricted actions, even when called by untrusted code. For example, a class that must call System.loadLibrary() to load native methods should make the call to loadLibrary() within the run() method of a PrivilegedAction. If your privileged code may throw a checked exception, implement it in the run() method of a PrivilegedExceptionAction instead. Be very careful when implementing this interface. To minimize the possibility of security holes, keep the body of the run() method as short as possible.
Passed To: AccessController.doPrivileged()
This exception class is a wrapper around an arbitrary Exception thrown by a PrivilegedExceptionAction executed by the AccessController.doPrivileged() method. Use getException() to obtain the wrapped Exception object.
Hierarchy: Object-->Throwable(Serializable)-->Exception-->PrivilegedActionException Thrown By: AccessController.doPrivileged()
This interface is like PrivilegedAction, except that its run() method may throw an exception. See PrivilegedAction for details.
Passed To: AccessController.doPrivileged()
This class represents a CodeSource and the associated PermissionCollection granted to that CodeSource by a Policy object. The implies() method checks to see whether the specified Permission is implied by any of the permissions granted to this ProtectionDomain. In Java 1.2, every class has an associated ProtectionDomain, which can be obtained with the getProtectionDomain() method of the Class object. Only applications that implement a custom ClassLoader should need to use this class.
Passed To: ClassLoader.defineClass(), AccessControlContext.AccessControlContext(), DomainCombiner.combine() Returned By: Class.getProtectionDomain(), DomainCombiner.combine()
This class represents a security provider. It specifies class names for implementations of one or more algorithms for message digests, digital signatures, key generation, key conversion, key management, secure random number generation, certificate conversion, and algorithm parameter management. The getName(), getVersion(), and getInfo() methods return information about the provider. Provider inherits from Properties and maintains a mapping of property names to property values. These name/value pairs specify the capabilities of the Provider implementation. Each property name has the form: service_type.algorithm_name The corresponding property value is the name of the class that implements the named algorithm. For example, say a Provider defines properties named "Signature.DSA", "MessageDigest.MD5", and "KeyStore.JKS". The values of these properties are the class names of SignatureSpi, MessageDigestSpi, and KeyStoreSpi implementations. Other properties defined by a Provider are used to provide aliases for algorithm names. For example, the property Alg.Alias.MessageDigest.SHA1 might have the value "SHA", meaning that the algorithm name "SHA1" is an alias for "SHA". Security providers are installed for a Java system in an implementation-dependent way. For Sun's implementation, the ${java.home}/lib/security/java.security file specifies the class names of all installed Provider implementations. An application can also install its own custom Provider with the addProvider() and insertProviderAt() methods of the Security class. Most applications do not need to use the Provider class directly. Typically, only security-provider implementors need to use the Provider class. Some applications may explicitly specify the name of a desired Provider when calling a static getInstance() factory method, however. Only applications with the most demanding cryptographic needs need to install custom providers.
Hierarchy: Object-->java.util.Dictionary-->java.util.Hashtable(Cloneable,java.util.Map,Serializable)-->java.util.Properties-->Provider Passed To: AlgorithmParameterGenerator.AlgorithmParameterGenerator(), AlgorithmParameters.AlgorithmParameters(), KeyFactory.KeyFactory(), KeyStore.KeyStore(), SecureRandom.SecureRandom(), Security.{addProvider(), insertProviderAt()}, java.security.cert.CertificateFactory.CertificateFactory(), javax.crypto.Cipher.Cipher(), javax.crypto.KeyAgreement.KeyAgreement(), javax.crypto.KeyGenerator.KeyGenerator(), javax.crypto.Mac.Mac(), javax.crypto.SecretKeyFactory.SecretKeyFactory() Returned By: Too many methods to list.
Signals that an exception has occurred inside a cryptographic service provider. Note that ProviderException extends RuntimeException and is therefore an unchecked exception that may be thrown from any method without being declared.
Hierarchy: Object-->Throwable(Serializable)-->Exception-->RuntimeException-->ProviderException
This interface represents a public cryptographic key. It extends the Key interface, but does not add any new methods. The interface exists in order to create a strong distinction between public and private keys. See also PrivateKey.
Hierarchy: (PublicKey(Key(Serializable))) Implementations: java.security.interfaces.DSAPublicKey, java.security.interfaces.RSAPublicKey, javax.crypto.interfaces.DHPublicKey Passed To: Identity.setPublicKey(), IdentityScope.getIdentity(), KeyPair.KeyPair(), Signature.initVerify(), SignatureSpi.engineInitVerify(), SignedObject.verify(), java.security.cert.Certificate.verify(), java.security.cert.X509CRL.verify() Returned By: java.security.Certificate.getPublicKey(), Identity.getPublicKey(), KeyFactory.generatePublic(), KeyFactorySpi.engineGeneratePublic(), KeyPair.getPublic(), java.security.cert.Certificate.getPublicKey()
This class adds two protected methods to those defined by ClassLoader. The defineClass() method is passed a CodeSource object that represents the source of the class being loaded. It calls the getPermissions() method to obtain a PermissionCollection for that CodeSource. It then uses the CodeSource and PermissionCollection to create a ProtectionDomain, which is passed to the defineClass() method of its superclass. The default implementation of the getPermissions() method uses the default Policy to determine the appropriate set of permissions for a given code source. The value of SecureClassLoader is that subclasses can use its defineClass() method to load classes without having to work explicitly with the ProtectionDomain and Policy classes. A subclass of SecureClassLoader can define its own security policy by overriding getPermissions(). In Java 1.2 and later, any application that implements a custom class loader should do so by extending SecureClassLoader, instead of subclassing ClassLoader directly. Most applications can use java.net.URLClassLoader, however, and never have to subclass this class.
Hierarchy: Object-->ClassLoader-->SecureClassLoader Subclasses: java.net.URLClassLoader
This class generates cryptographic-quality pseudo-random bytes. Although SecureRandom defines public constructors, the preferred technique for obtaining a SecureRandom object is to call one of the static getInstance() factory methods, specifying the desired pseudo-random number-generation algorithm, and, optionally, the desired provider of that algorithm. Sun's implementation of Java ships with an algorithm named "SHA1PRNG" in the "SUN" provider. Once you have obtained a SecureRandom object, call nextBytes() to fill an array with pseudo-random bytes. You can also call any of the methods defined by the Random superclass to obtain random numbers. The first time one of these methods is called, the SecureRandom() method uses its generateSeed() method to seed itself. If you have a source of random or very high-quality pseudo-random bytes, you may provide your own seed by calling setSeed(). Repeated calls to setSeed() augment the existing seed instead of replacing it. You can also call generateSeed() to generate seeds for use with other pseudo-random generators. generateSeed() may use a different algorithm than nextBytes() and may produce higher-quality randomness, usually at the expense of increased computation time.
Hierarchy: Object-->java.util.Random(Serializable)-->SecureRandom Passed To: Too many methods to list. Returned By: SecureRandom.getInstance() Type Of: SignatureSpi.appRandom
This abstract class defines the service-provider interface for SecureRandom. A security provider must implement a concrete subclass of this class for each pseudo-random number-generation algorithm it supports. Applications never need to use or subclass this class.
Hierarchy: Object-->SecureRandomSpi(Serializable) Passed To: SecureRandom.SecureRandom()
This class defines static methods both for managing the list of installed security providers and for reading and setting the values of various properties used by the Java 1.2 security system. It is essentially an interface to the ${java.home}/lib/security/java.security file that is included in Sun's implementation of Java. getProviders() is the most generally useful method; it returns an array of installed Provider objects. In Java 1.3, two new versions of getProviders() return an array of installed providers that implement the algorithm or algorithms specified by the String or Map argument.
This class is a Permission subclass that represents access to various methods of the Policy, Security, Provider, Signer, and Identity objects. SecurityPermission objects are defined by a name only; they do not use a list of actions. Important SecurityPermission names are "getPolicy" and "setPolicy", which represent the ability query and set the system security policy by invoking the Policy.getPolicy() and Policy.setPolicy() methods. Applications do not typically need to use this class.
Hierarchy: Object-->java.security.Permission(Guard,Serializable)-->BasicPermission(Serializable)-->SecurityPermission
This class computes or verifies a digital signature. Obtain a Signature object by calling one of the static getInstance() factory methods and specifying the desired digital signature algorithm and, optionally, the desired provider of that algorithm. A digital signature is essentially a message digest encrypted by a public-key encryption algorithm. Thus, to specify a digital signature algorithm, you must specify both the digest algorithm and the encryption algorithm. The only algorithm supported by the default "SUN" provider is "SHA1withDSA". Once you have obtained a Signature object, you must initialize it before you can create or verify a digital signature. To initialize a digital signature for creation, call initSign() and specify the private key to be used to create the signature. To initialize a signature for verification, call initVerify() and specify the public key of the signer. Once the Signature object has been initialized, call update() one or more times to specify the bytes to be signed or verified. Finally, to create a digital signature, call sign(), passing a byte array into which the signature is stored. Or, pass the bytes of the digital signature to verify(), which returns true if the signature is valid or false otherwise. After calling either sign() or verify(), the Signature object is reset internally and can be used to create or verify another signature.
Hierarchy: Object-->SignatureSpi-->Signature Passed To: SignedObject.{SignedObject(), verify()} Returned By: Signature.getInstance()
Signals a problem while creating or verifying a digital signature.
Hierarchy: Object-->Throwable(Serializable)-->Exception-->GeneralSecurityException-->SignatureException Thrown By: Too many methods to list.
This abstract class defines the service-provider interface for Signature. A security provider must implement a concrete subclass of this class for each digital signature algorithm it supports. Applications never need to use or subclass this class.
Subclasses: Signature
This class applies a digital signature to any serializable Java object. Create a SignedObject by specifying the object to be signed, the PrivateKey to use for the signature, and the Signature object to create the signature. The SignedObject() constructor serializes the specified object into an array of bytes and creates a digital signature for those bytes. After creation, a SignedObject is itself typically serialized for storage or transmission to another Java thread or process. Once the SignedObject is reconstituted, the integrity of the object it contains can be verified by calling verify() and supplying the PublicKey of the signer and a Signature that performs the verification. Whether or not verification is performed or is successful, getObject() can be called to deserialize and return the wrapped object.
Hierarchy: Object-->SignedObject(Serializable)
This deprecated class was used in Java 1.1 to represent an entity or Principal that has an associated PrivateKey that enables it to create digital signatures. As of Java 1.2, this class and the related Identity and IdentityScope classes have been replaced by KeyStore and java.security.cert.Certificate. See also Identity.
Hierarchy: Object-->Identity(java.security.Principal,Serializable)-->Signer
This exception is thrown if a Key cannot be retrieved from a KeyStore. This commonly occurs when an incorrect password is used.
Hierarchy: Object-->Throwable(Serializable)-->Exception-->GeneralSecurityException-->UnrecoverableKeyException Thrown By: KeyStore.getKey(), KeyStoreSpi.engineGetKey()
This class is used internally to provide a mechanism for delayed resolution of permissions. An UnresolvedPermission holds a textual representation of a Permission object that can later be used to create the actual Permission object. Applications never need to use this class.
Hierarchy: Object-->java.security.Permission(Guard,Serializable)-->UnresolvedPermission(Serializable) Copyright © 2001 O'Reilly & Associates. All rights reserved. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|