Hi David,
Currently there is DefaultPrincipal type and it wraps a subject; When I talk
about default principal I mean default principal name.
jetty interceptor code
(org.apache.geronimo.jetty.interceptor.SecurityContextBeforeAfter) generates
a subject for a default principal with the help of the utility code that
populates a subject will all sorts of principals (domain, realm, etc); then
interceptor code registers this subject with the context and inserts another
principal (identification principal) into it;
I want to avoid all of that;
All logins should go through the login-service; currently I'm using this
api:
public interface ILoginService {
public SubjectId login(String securityRealmName, CallbackHandler cbh)
throws LoginException;
Subject getSubject(SubjectId subjectId);
...
}
When authentication succeeds, login-service creates identification principal
and inserts it into the subject; then it is using the same subject-id to
insert a subject into it's logins map; After that a subject is frozen
(read-only). When you make a call on context-manager (eg
cm.setCurrentCaller()) the check is made to see that the login-service knows
about this subject by using it's identification principal; In other words
you can not insert an unauthenticated subject into the context;
I agree with you that the default principal and run-as principals should be
authenticated on application start-up; (That was my thinking as well)
Interceptor code will receive default (and run-as) subjects and will call
context-manager.setCurrentCaller() and friends when needed; (no calls to
context-manager.register-subject)
Default principal authentication: an obvious way is to specify credentials
in the plan; Do not like it much but it should be mentioned; We need to deal
with plan secrets anyway... so when we put secret-vault in place it would be
less of a problem;
It is also true (as you mention) that you will have to setup a "default
user" in a login-domain; if an application is completely security unaware
you can configure it's security realm with dummy login module that accepts
any principal; If an application is security-sensitive you must define users
in the login domains that you use.
How to authenticate default principal without specifying credentials: This
could be done if we setup deployer (a server in fact) with a secret key;
Then deployer will vouch for the default principal by creating
authentication assertion for the default principal and signing it with it's
secret key (secure hash here, not pk signature). At authentication time
login module will receive this assertion and verify it with the server;
Setting up a server with a secret key is something we can do and use for
many purposes.
Here is a flow: define default-principal by a security role; find a
principal mapping for that role with the 'run-as' attribute set to true;
This is our default principal; authenticate this principal either by using
embedded credentials or by assertion at application start-up time; Pass
authenticated subject for the default-principal to the interceptor (or any
other code that needs it).
Comments?
Simon
>On Jan 30, 2006, at 2:46 AM, Simon wrote:
>
>> In login-service re-factoring, I'd like to unify treatment of the
>> default
>> principal.
>
>I think this is interesting and important, but I'm having trouble
>following what you are proposing. Could you provide more details?
>
>One overall question I have is, where exactly are we dealing with a
>default principal? When I think about our security I always start
>from a Subject. To deal with web containers we wrap the subject in a
>principal, and the subject of course is filled up with many principals.
>>
>> Default principal should be designated by a role, not as an
>> instance of a
>> principal; To find an instance of a default-principal find a
>> principal that
>> is mapped to a role that has 'run-as' attribute set to true (same as
>> 'run-as' principal)
>
>Again, where do we do this? My understanding of the jetty and
>openejb code is that we find a subject based on a specified run-as
>role. I don't know how the tomcat integration does this.
>
>> Default (and run-as) principal should be logged in as any other
>> principal;
>> Login service will create a subject with all types of principals
>> that are
>> applicable to the specified security realm and login domain;
>> (Currently this
>> is done by utility code, not login service)
>>
>> You would not be able to insert a subject into the context unless
>> subject is
>> authenticated (contains valid identification principal).
>
>Are you proposing a runtime check that the subject is valid in some
>way, or that we modify our code so all subjects we use have come from
>a JAAS login?
>>
>> Authentication of a default (run-as) principal can be done in
>> several ways;
>> Most obvious is to specify authentication credential when mapping
>> default
> (run-as) principal; (There are other ways such that you do not have to
> specify credentials at all (later)).
>
>This is an interesting idea. I like that it would result in subjects
>always getting set up in login modules. However I think it could
>complicate setting up default subjects. It also means you have to
>have enough control over the login authentication service that you
>can create at least one "default user" with the appropriate
>principals. Is this sure to be the case?
>
>I await your explanation of how to do this without credentials :-).
>With credentials, it seems to me that you are likely to distribute
>the credentials wherever the plan is visible.
>>
>> I looked at interceptors and it seems that default-principal is either
>> passed in, or subject for the default principal is passed in; So
>> interceptors can either perform default-principal (run-as)
>> authentication or
>> have default (run-as) subject passed in that is already
>> authenticated; Then
>> an interceptor can insert default (run-as) principal into context
>> without
>> any additional steps;
>
>Which interceptors specifically? I think that if we authenticate a
>default subject, it should be done when the app is started, not for
>any particular request.
>>
>> It looks like interceptor code could be optimized so it does not login
>> default (run-as) principals more than once;
>
>I don't see why it should ever login a run-as principal.
>>
>> Comments?
>
>I'd like more specific details
>
>thanks
>david jencks
>
>>
>> Simon
>>
