Advertisement

Security Constraints

Bill Venners: What are security constraints?

Bob Scheifler: Security constraints are the object mechanism we use to describe what kind of network security we want. We talked before about mutual authentication, confidentially, and integrity. I need some way of describing which of those I want. I don't necessarily want confidentially on every call. Sometimes I do and sometimes I don't. To specify what kind of security you want, you provide objects that implement an interface called SecurityConstraint. This interface has one method, which is, in fact, not very interesting. So most people can just ignore that method.

The basic security constraint classes we have are very simple. They are essentially the equivalent of Boolean constants. One of them is ClientAuthentication. It has two public static final constant fields, YES and NO. YES means I want client authentication. I want the client to authenticate to the server. And NO means the client should not authenticate to the server.

There is another class called ServerAuthentication. It also has YES and NO constants. YES means the service should authenticate itself to the client. NO means the server should not authenticate. There is a Confidentiality class that has YES and NO constants. And an Integrity class with YES and NO constants. So it is very simple. You do or you don't want those forms of security.

In the case of server authentication, just saying you want the server to authenticate itself isn't enough. You want to make sure the server authenticates as someone in particular, not just that it authenticates. So we have another security constraint class we call ServerMinPrincipal (Min as in minimum). We specify there the principal or principals the server should authenticate as. Principals are a naming mechanism. I specify the principals I expect the server to authenticate as. The ServerMinPrincipal constraint means that the sever must authenticate at least as this identity. It might authenticate as more, I don't care, but it has to at least authenticate as this identity.

Those are the basic constraints. There are more. There are many other constraints that are used to refine how a client will authenticate itself to a service. ClientAuthentication.NO, for example, is a way of refining how I want to authenticate. It means I want to remain anonymous. You are probably never going to use most of the NOs. They are there for completeness of the model. If you don't care about something, the way to say you don't care is to say nothing, rather than to say NO.

Bill Venners: I just don't inject any constraints into the proxy.

Bob Scheifler: If you don't care about integrity, you just won't inject any integrity constraints. You typically wouldn't say no. But a place where I would say no is if I want to be anonymous. I don't want you to know who I am. So client authentication no is a useful constraint if you want anonymity.

There are cases for client authentication where you don't want to be completely anonymous. You simply want to limit how much of your identity to expose to a server. When I talk to my bank, for example, I don't necessarily want the bank to know that I am a Sun employee. Even though I may have the ability to prove that I am a Sun employee, when I talk to my bank, I just want to prove that I am a customer of the bank. Or if I go to the Department of Motor Vehicles, I want to prove that this is my driver's license, but I don't want to give them my Visa card number. We have other constraints that control which subset of my collective client identity I will expose to the server.