Sponsored Link •
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
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
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
YES means the service should authenticate itself to the
NO means the server should not authenticate.
There is a
Confidentiality class that has
NO constants. And an
Integrity class with
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
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
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.