Hi there!
> You still need to address the issue of a unique name for the JASPIC app > context. I see your point. However, tomcat's implementation of uniqueness is against JASPIC 1.1 specification. We must somehow document this feature. > > 1) I have prepared mechanism for registration embedded JASPIC modules > > 2) Callback handler is singleton now > > 3) Implemented JAAS Subject's support (it turned out, that it is > mandatory). > > 4) BASIC and DIGEST authenticators has been ported to JASPIC > > I think these modules need to be carefully refactored though, then I will > > prepare some tests. > > Why do you think these modules need to be refactored? Given the security > nature of this code and that what you have currently is largely copied > directly from the existing implementations, I'd be wary of making any > changes without a good reason for doing so. Yes, we must be very careful with security implementations. However, I would decouple JASPIC code from authentication algorithms and put them into separate classes. > 5) Fixed some bugs in implementation, such as lack of session caching > > 6) Currently, I am working on some javadoc's, but I'll commit them later. > > Remember, little and often is better than a few larger code dumps. The > recent commits have been fine but I would prefer to see 1 or 2 commits a > day rather than a batch of 10+ commits once a week. I agree, however I was intensively using rebase and squashing for commit rewriting in order to get "feature per commit". I think it depends on architectural tasks - currently we have architectural stuff done, so next commits will require less rewriting. > 1) I need some convenient way to get user roles from Realm. I assume, that > > every Principal is GenericPrincipal, but I guess that's not right. > > What for? The best way to handle this depends on why/where that > information is needed. I need this info in order to construct GenericPrincipal using callbacks. Currently, Realm is returning GenericPrincipal, however, implementation is hidden behind Principal interface. I need to do casting to get GenericPrincipal object, because Principal doesn't have getRoles() method. > > 2) We need find a easy way for configuring embedded JASPIC modules. For > > example, form authentication requires login page and error page. I think > > that these parameters can be passed to JASPIC provider directly, but I'm > > not sure. > > Currently the ContextConfig registers a new TomcatAuthConfigProvider for > each web application. > > The TomcatAuthConfigProvider creates (lazily) a TomcatAuthConfig. > > The TomcatAuthConfig creates (lazily) TomcatServerAuthContext with all > available modules. > > The TomcatAuthConfig then looks up the authentication type obtained from > the request and maps it to the right module. > > Initialising all the modules when - typically - only one is required > looks wrong to me. I'd expect the ContextConfig to specify (possibly > even create and configure) the required modules and pass those to the > TomcatAuthConfigProvider instance for the web application. Yes, I agree, that it's better solution. I am not sure about constructing auth modules in ContextConfig. May be we can pass LoginConfig info into provider, and construct modules inside. -- Thanks, Fjodor
