By default, all requests to use your resource coming from anyone but you are denied. Access control polices can override that by allowing different types of access to your resources, or by explicitly denying different types of access.
Each statement in an AWS access control policy takes the form: "A has permission to do B to C where D applies".
Note that an AWS access control policy should not be confused with the similarly named "POST form policy" concept used in Amazon S3.
There is only one Policy object installed in the runtime at any given time. A Policy object can be installed by calling the setPolicy method. The installed Policy object can be obtained by calling the getPolicy method.
If no Policy object has been installed in the runtime, a call to getPolicy installs an instance of the default Policy implementation (a default subclass implementation of this abstract class). The default Policy implementation can be changed by setting the value of the "policy.provider" security property (in the Java security properties file) to the fully qualified name of the desired Policy subclass implementation. The Java security properties file is located in the file named <JAVA_HOME>/lib/security/java.security. <JAVA_HOME> refers to the value of the java.home system property, and specifies the directory where the JRE is installed.
Application code can directly subclass Policy to provide a custom implementation. In addition, an instance of a Policy object can be constructed by invoking one of the getInstance factory methods with a standard type. The default policy type is "JavaPolicy". See Appendix A in the Java Cryptography Architecture API Specification & Reference for a list of standard Policy types.
Once a Policy instance has been installed (either by default, or by calling setPolicy), the Java runtime invokes its implies when it needs to determine whether executing code (encapsulated in a ProtectionDomain) can perform SecurityManager-protected operations. How a Policy object retrieves its policy data is up to the Policy implementation itself. The policy data may be stored, for example, in a flat ASCII file, in a serialized binary file of the Policy class, or in a database.
The refresh method causes the policy object to refresh/reload its data. This operation is implementation-dependent. For example, if the policy object stores its data in configuration files, calling refresh will cause it to re-read the configuration policy files. If a refresh operation is not supported, this method does nothing. Note that refreshed policy may not have an effect on classes in a particular ProtectionDomain. This is dependent on the Policy provider's implementation of the implies method and its PermissionCollection caching strategy.
@author Roland Schemers
@author Gary Ellison
@version 1.103, 11/17/06
@see java.security.Provider
@see java.security.ProtectionDomain
@see java.security.Permission
This is an abstract class for representing the system policy for Subject-based authorization. A subclass implementation of this class provides a means to specify a Subject-based access control {@code Policy}.
A {@code Policy} object can be queried for the set ofPermissions granted to code running as a {@code Principal} in the following manner:
policy = Policy.getPolicy(); PermissionCollection perms = policy.getPermissions(subject, codeSource);The {@code Policy} object consults the local policy and returnsand appropriate {@code Permissions} object with thePermissions granted to the Principals associated with the provided subject, and granted to the code specified by the provided codeSource.
A {@code Policy} contains the following information.Note that this example only represents the syntax for the default {@code Policy} implementation. Subclass implementations of this classmay implement alternative syntaxes and may retrieve the {@code Policy} from any source such as files, databases,or servers.
Each entry in the {@code Policy} is represented asa grant entry. Each grant entry specifies a codebase, code signers, and Principals triplet, as well as the Permissions granted to that triplet.
grant CodeBase ["URL"], Signedby ["signers"], Principal [Principal_Class] "Principal_Name" { Permission Permission_Class ["Target_Name"] [, "Permission_Actions"] [, signedBy "SignerName"]; }; The CodeBase and Signedby components of the triplet name/value pairs are optional. If they are not present, then any any codebase will match, and any signer (including unsigned code) will match. For Example, grant CodeBase "foo.com", Signedby "foo", Principal com.sun.security.auth.SolarisPrincipal "duke" { permission java.io.FilePermission "/home/duke", "read, write"; }; This grant entry specifies that code from "foo.com", signed by "foo', and running as a {@code SolarisPrincipal} with thename, duke, has one {@code Permission}. This {@code Permission}permits the executing code to read and write files in the directory, "/home/duke". To "run" as a particular {@code Principal}, code invokes the {@code Subject.doAs(subject, ...)} method.After invoking that method, the code runs as all the Principals associated with the specified {@code Subject}. Note that this {@code Policy} (and the Permissionsgranted in this {@code Policy}) only become effective after the call to {@code Subject.doAs} has occurred.
Multiple Principals may be listed within one grant entry. All the Principals in the grant entry must be associated with the {@code Subject} provided to {@code Subject.doAs}for that {@code Subject} to be granted the specified Permissions.
grant Principal com.sun.security.auth.SolarisPrincipal "duke", Principal com.sun.security.auth.SolarisNumericUserPrincipal "0" { permission java.io.FilePermission "/home/duke", "read, write"; permission java.net.SocketPermission "duke.com", "connect"; }; This entry grants any code running as both "duke" and "0" permission to read and write files in duke's home directory, as well as permission to make socket connections to "duke.com". Note that non Principal-based grant entries are not permitted in this {@code Policy}. Therefore, grant entries such as:
grant CodeBase "foo.com", Signedby "foo" { permission java.io.FilePermission "/tmp/scratch", "read, write"; }; are rejected. Such permission must be listed in the {@code java.security.Policy}. The default {@code Policy} implementation can be changed bysetting the value of the {@code auth.policy.provider} security property tothe fully qualified name of the desired {@code Policy} implementation class. @deprecated as of JDK version 1.4 -- Replaced by java.security.Policy.java.security.Policy has a method:
public PermissionCollection getPermissions (java.security.ProtectionDomain pd)and ProtectionDomain has a constructor:
public ProtectionDomain (CodeSource cs, PermissionCollection permissions, ClassLoader loader, Principal[] principals)These two APIs provide callers the means to query the Policy for Principal-based Permission entries. @see java.security.Security security properties
See Domain Model 2.7
policies configuration file
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |