geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon" <si...@godik.com>
Subject login-service refactoring: uniform treatment for the default principal
Date Mon, 30 Jan 2006 10:46:57 GMT
In login-service re-factoring, I'd like to unify treatment of the default
principal.

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)

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).

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)).

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;

It looks like interceptor code could be optimized so it does not login
default (run-as) principals more than once;

Comments?

Simon


Mime
View raw message