On Tue, 2011-08-09 at 02:53, Peter wrote:
> Following up on recent discussions about security.
>
> Java, River / Jini Security features are advanced programming concepts.
>
> You need security policies, need to know what permissions each codebase
> requires to function. A key server is essential, along with user Subjects
> and Principals (including preserving the SubjectDomainCombiner accross
> privileged calls. Then you've got Proxy trust, verification and dynamic
> grants.
>
> I've thought previously about having separate releases, one for private
> networks, the other for untrusted networks. Leading me to consider
> modularity, to avoid forking, that, classloader issues and codebase
> annotation loss. But modularity appears to have stalled. A lot of the code
> I'm writing is in different branches, I'm not great at merging, and will be
> time poor soon, so I'm concentrating on wrapping up my recent security work.
>
I don't see separate releases solving anything. The security setup
should just be a matter of selecting a different Configuration file,
depending on what level and type of transport security and
confidentiality you want. I'd picture supplying a minimal-security
configuration and a maximal-lockdown config for Kerberos and SSL.
> Does anyone have any suggestions for annotations? So developers can weave in
> security later, allowing them to get up and running with River in a local
> network first, then learn security later?
>
Some random thoughts:
- Security can be decomposed into
- Authentication
- Authorization
- Integrity of communications
- Confidentiality of communications
- Jeri does a great job with Authentication (can use Kerberos or X509
certs), Cinfidentiality and Integrity (through SSL, https, Kerberos
endpoints).
- The SecurityPolicy model was originally intended to support
codebase-based security (i.e. permissions are applied to a
ProtectionDomain associated with the source of the code).
- JAAS extension glued on Subject-based decisions to the SecurityPolicy
model after-the-fact.
I've been gradually becoming convinced that the JAAS security model
(i.e. SubjectDomainCombiner etc) is not very good for subject-based
authorization. The basic business need for a service is to answer the
question "Is Bob allowed to place a purchase order?", where Bob's
authorization might be subject to change over time, or might be subject
to additional business rules. Seems like in order to enforce that
decision using the SecurityPolicy model, we end up needing elaborate
constructs (e.g. revokable permissions, remote policy files,
classloader/protection domain magic, dynamic policy lookup, etc).
I can't help wondering if the deployer's life is made easier if we just
say "Authorization is the service's problem" for now. Possibly we could
design an AuthorizationService that the service implementor could
delegate to for that decision. At least then, supporting a cached,
dynamic authorization policy (for service-,ethod-level authorization)
wouldn't need so much digging around at low levels. The
DynamicPolicyProvider already allows for assigning limited system
privileges to a proxy class.
Thoughts?
> Example: an annotation and the boilerplate code that needs to be weaved in by
> an annotation processor.
>
EJB3 includes @RolesAllowed. I wouldn't want to couple to the Java EE
API, but something similar would work. Then it wouldn't be a major
trick to create a delegating proxy that checked the required security
roles.
Alternately, just make the client subject available and the app
developer could use something like Spring Security to implement the
method-level authorization. Again I wouldn't want to couple River to
Spring in any way, but the required liaison classes could be in a
separate support package.
> Cheers,
>
> Peter.
