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
