Not sure what you mean by the 'interceptor would be creating one of these (subjects?)'
I want to emphasize that interceptors (or any code for that matter) should be passed authenticated subject(s) and hopefully we can avoid a call to ContextManager.registerSubject() altogether; The only calls an interceptor would do as far as subject is concerned: ContextManager.setCurrentCaller() and setNextCaller(); I have to think more about how ServerSecurityInterceptor that is doing csi-v2 authentication will interact with the login-service; Simon >> When default and run-as principals are in-effect they should be >> treated the >> same way as any other principal; (eg granting of privilege to perform >> certain tasks); That means we should track these objects in the >> login-service and believe that these objects are authentic; We rely >> on the >> login-service to produce principal objects that we believe to be >> authentic, >> not the interceptor code; >> >> There is a kludge possible such as granting interceptor code-source >> privilege to insert subjects into the context, > >In openejb the default and run-as subjects are passed into the >container, so from the container's perspective it doesn't care where >they came from. I also find it very weird that an interceptor would >be creating these because it seems to violate a separation of concern. > >> but this is authentication by >> assertion is disguise; better to be done explicitly; on top of that >> any code >> that inserts subjects into the context also inserts a bunch of >> principals >> trying to compensate for not doing authentication and should be >> avoided; > >Now as for where the subjects or principals come from I just want to >see simple easy to understand code. If logging them in is cleanest, >then I say go for it (just keep an eye out for complexity). > >-dain
