public interface SubjectDomain
Securityto mark a
ProtectionDomainadded to the stack that represents an authenticated
Typically in non-distributed systems, a
Subject is represented
Thread and all
Subject is injected into every
present on the call stack. Code is always trusted, or at least it must be at the time the
Subject is authenticated.
However in a distributed system, because code trust and Subject's are
separate concerns, methods have been provided in
Security to push a
onto the stack instead of injecting Principal's into all ProtectionDomain's on
the stack, this avoids mistakenly elevating privileges of less trusted
code, if present on a call stack at the time the doAs subject method is called.
When using these methods, the security Policy needs to be written to grant Permission to code signer certificates and Principals separately.
For example, a RemotePolicy service is updated by an Administrator client using PermissionGrant's, however one of these grants is not signed by a trusted Certificate. Ordinarily this PermissionGrant would run with the privileges of the administrator, but because code trust and user trust should be considered separate concerns in a distributed system, the administrator is unable to make these PermissionGrant's in the presence of untrusted code.
These methods apply the principle of least privilege to Subject's as well as code. The privileges allowed will be the intersection of Permission granted to each ProtectionDomain on the call stack.
These methods require a River or Jini Policy provider to be installed. The
SubjectDomain is a dynamic ProtectionDomain, it contains no Permission,
it always consults the current
Security.doAsPrivileged(javax.security.auth.Subject, java.security.PrivilegedAction, net.jini.security.SecurityContext),
Security.doAsPrivileged(javax.security.auth.Subject, java.security.PrivilegedExceptionAction, net.jini.security.SecurityContext),
|Modifier and Type||Method and Description|
Copyright 2007-2013, multiple authors.
Licensed under the Apache License, Version 2.0, see the NOTICE file for attributions.