Maybe this time? What about when a client communicates with a remote server?
For example, a remote policy service, where an admin has decided to update all nodes with new policy and a process executes that running under admin privileges. Lets say also that the administrator has spki authority certificates that dynamically assign his or her priviledges (using a dynamic policy) during an ssl jeri session at the server. An alternative to spki is to use trusted X509 certificates and authentication, that would not require a dynamic policy grant, I just thought I'd throw in an SPKI example. Under the existing framework, if semi trusted code (from another company) can find a way to be run on that admin thread, it can dictate policy, for all nodes in a djin. This might allow an attacker from one company get access to procurement systems etc. Instead, if the admin only has a Subject ProtectionDomain added to the call stack, this attack is no longer possible and it becomes more viable to mix semi trusted and trusted code in a system. These use cases also help us model which permissions Subjects can and cannot have, for instance some Permissions only apply in a local context, like AWTPermission, so these permissions have no place at the services server, but since ProtectionDomains are not serialised, only the subject, a different SubjectProtectionDomain can be constructed at or by the server. This means we now have more than one category: LocalSubjectProtectionDomain RemoteSubjectProtectionDomain This is similar to how static Permissions are automatically granted to applets. So the permissions granted by default in these domains would be relative to where the Subject is running and where it originated from. So a Principal granted AllPermission, such as an administrator, would have this permission defined in a policy and certificates would be used to authenticate the admin, even though the admin is defined in a RemoteSubjectProtectionDomain, the static domain permissions are merged by the local policy provider with those of the policy. Untrusted code could no longer hijack the administrators privileged thread. So this preserves the intersection model where all domains must have Permission, rather than elevating the privileges of a thread. It starts to become simpler to define and model when we make this minor subtle change to subjectDomainCombiner. Peter.
