The Java 2 Security API is great at what it does. Problem is, it can't actually do everything most developers actually want it to do.
What it can be used to do very effectively (without an inordinant amount of development work, or a significant performance hit) is secure loosely-coupled components from potentially malicious co-located components. For example, an applet container can sandbox an applet. A JNLP (Web Start) container can sandbox dynamicly loaded applications so they cannot access certain resources on the host computer.
In the two times I have employed the Java Security API to design a solution for a client a gaping hole in the Security API design has appeared. The API is hard-coded to a specific use-pattern, which is requesting a particular permission. The logical compliment usage-pattern, querying for available permissions, is missing from the API. So in the Interior Decorator's Studio app I'm developing I can guarantee, for example, that a user never changes the Color Scheme to "Fuschia&Pink". That's very easy. What I can't do is enumerate what Color Schemes a user is allowed to use.
I can pretty easily create sandboxes, but not very hospitable ones that other developers want to play in. I think of Java sandboxes more like those invisible force-field shielded detention rooms you see on old Star Trek episodes: in those rooms you don't know you aren't allowed to go out until you try leaving and either do or do not receive an electric jolt (analogous to a Java SecurityException). How come there's no sign anywhere, saying,"Don't go here!" And wouldn't it have just been reassuring for them to have posted a "May Be Used Without Intensense Force-Field Shock" sign over the toilet? Instead, the poor detainees are left to ponder, squat and hope.
Sandboxed components are in much the same dilema without a security query API. You just don't know you aren't allowed to do anything until you actually try to do it.
2:39:32 PM 
|
