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
