On 15/06/2015 16:42, Fjodor Vershinin wrote: > 2015-06-15 17:53 GMT+03:00 Mark Thomas <ma...@apache.org>: > >> On 15/06/2015 12:14, Fjodor Vershinin wrote: >>> Hi, all! >>> Here is my report for previous week. I'd ported JASPIC api classes and >>> implemented skeleton for JASPIC support. The skeleton was implemented >> using >>> plan proposed by Mark. It contains very basic AuthConfigFactory, callback >>> handler's, and JaspicAuthenticator. I did some hacking on weekend with >>> Arjan's suite, tried to execute some tests on current implementation and >>> seems it works. >>> You can have a look at latest code in this branch >>> https://github.com/fjodorver/tomcat/tree/feature/jaspic-implementation. >> >> I'll start working through those patches, reviewing them and integrating >> them into trunk. >> >>> However, I have faced some open problems. >>> One is about picking up existing AuthenticatorBase for extending with >>> JASPIC stuff. It looks like extending this class is good solution, >> because >>> it contains a lot of security logic, such as I am not sure that I must >>> implement it by myself, because it's out of JASPIC scope. Could you >> confirm >>> that? >> >> Such as? You will need to be more specific. > > For example, it decides if security constraints should be applied or not, > validates principles and roles and so on.
Integrating JASPIC into Tomccat is in scope and all of that comes under that heading. I'd expect the JaspicAuthenticator to extend Authenticator base to start with. Once all the authenticators are implemented through JASIC then the AuthenticatorBase and JaspicAuthenticator may end up merging. (No point having a super class that is only ever going to be extended by one class.) >>> Second question is about integrating and replacing current authentication >>> mechanisms with JASPIC modules. From my current point of view, I would >>> implement that by registering providers at context initialization, for >>> example in ContextConfig.authenticatorConfig(). We can register different >>> providers depending on context's login config, or use the same provider, >>> which returns different authentication modules. Anyway, we need to >>> implement some custom logic in authenticatorConfig() method. My current >>> proposal is to implement special management for jaspic authentication >>> methods, for example JASPIC-BASIC and JASPIC-DIGEST would use the same >>> JaspicAuthenticator, however they are handled by different JASPIC >> modules. >>> Whenever all methods be ported to JASPIC platform we can remove "JASPIC" >>> string from authentication methods, and then we can handle all >>> authentication types the same way. >> >> What is the question? > > Question is that correct? Or can I feel free to remove old auth mechanisms > from there? The general direction looks good. Keep the old ones and the new ones in parallel for now. Mark >>> Third problem is JAAS subjects. I use special callback in order to bind >>> principal and group callbacks into tomcat's principal. Is it correct >>> solution, or I need to build JAAS subject, and then convert it into >>> Tomcat's principal? >> >> I don't see any reason to build a JAAS subject (at the moment). Do you? >> > Neither me. May be Arjan can share some thoughts on this. > >> >>> Currently, I want to proceed with second question in order to port BASIC >>> authentication to JASPIC platform, but I need confirmation that I am >> moving >>> in right direction. >> >> The current direction looks good to me. I'll add any detailed comments >> to the commits as I review them. >> >> Mark >> >> -- > Thanks, > Fjodor > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
