Hmm,
Very eloquently put, you describe typical corporate IT behaviour, I
can't refute that.
In most if not all cases Subject.doAs is executed only in the presence
of trusted code or code assumed trusted.
And yet, I'd like to have the ability to run as a Subject with less
trusted code, call it an itch to scratch, if you like.
The code in question is not completely untrusted, it's partly trusted,
written by another company for collaboration, but not trusted enough to
grant AuthPermission("doAs") locally.
Perhaps if I narrowed it down only to two new methods, and no property
to set, it might not seem as big a burden to carry:
public static <T> T doAs(final Subject subject,
final PrivilegedAction<T> action)
public static <T> T doAs(final Subject subject,
final PrivilegedExceptionAction<T> action)
throws PrivilegedActionException
When I think about it, the doAsPrivileged methods aren't really
required, because all I'd like to do in this case, is run as the
Subject, without having to grant AuthPermission "doAs". However I'd
like to run as a Subject with the SecurityContext returned by
Security.getContext(), rather than the AccessControlContext alone. I'd
like to allow the Subject to be authorised by the Service, for access
control on the server, without granting much permission locally.
These doAs methods in this case cannot elevate Permission, they can
reduce Permission to that which the Subject has in common with other
code on the stack, but it cannot be used by code to gain privilege if it
uses a custom DomainCombiner that extends SubjectDomainCombiner.
Would this be an acceptable compromise?
In future, we can look at other tools to assist with simplifying
security, such as static bytecode analysis or FindBugs perhaps.
Regards,
Peter.
Dan Creswell wrote:
"But what if we want to use a service with a smart proxy without granting
trust? So I can use it while running as my Subject, allowing me to use my
public credentials for authorisation to run as my Subject on the services
server (with another set of Principals assigned by the service server),
without granting smart proxy code my local Principal Permissions from my
local domain. I want to allow Subjects to cross authority domains
(personal, company and country network boundaries), where trust relations
aren't implicit."
"Penny for your thoughts?"
>From experience, where security really matters seemingly trust relations
aren't implicit. There are long discussions about ensuring that a user of a
service is who they say they are so they can be billed (amongst other
things). Discussions extend further to SLA's, load that is acceptable,
responses that are acceptable etc.
In cases where security doesn't matter it's often a case of "buyer beware".
Banks will often go as far as to bring in and certify particular .jars and
not sanction any use of any other .jar or sourcing of code from e.g. an
external maven repository.
So, whilst we could support all these bits and pieces of security, I'm not
sure of the value. It might allow a great deal of flexibility, all sorts of
options but maybe the world-at-large doesn't need them because the way it
deals in security is rather more polarised? And supporting all these
different options makes verification that security is, in fact, maintained
and not open to compromise ever more challenging.
I'm still left with a feeling that says "if people want co-operation in a
secure environment, they will take the simplest means possible to create
enough security and no more". Which means virtual networks, firewalls,
VPNs, static validation of code, certificates etc.
Or put another way, for all but a few security is an exercise in effort
versus risk that comes down to "don't bother" or "secure everything to the
finest detail". Where would untrusted code be acceptable in such a world?
