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. > 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? > 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? > 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 > > 2015-06-11 11:38 GMT+03:00 Mark Thomas <ma...@apache.org>: > >> (primarily for Fjodor but feel free to comment as you see fit) >> >> Consensus to date is that a Valve will be the best integration point. >> >> Given that the implementation will need access to Tomcat's internals, >> I'd suggest either use the existing org.apache.catalina.authenticator >> package or create a new org.apache.catalina.jaspic package >> >> I can think of a couple of different ways for you to get started. Feel >> free pick one (or more) of these or choose your own. >> >> 1. AuthConfigFactory >> - Create the Tomcat specific AuthConfigFactoryImpl (just stub out >> the methods to start with >> - Fix the various issues with AuthConfigFactory >> - Replace the stubs with actual implementations and provide any >> additional supporting code as you go. >> >> 2. Authenticator >> - Create a JaspicAuthenticator class (will need to be a Valve). >> - To start just have the Valve pass the request/response down the >> pipeline >> - Register a new web.xml authentication method "JASPIC-BASIC" and >> link it to the new Valve the same way the BasicAuthenticator is >> linked to the "BASIC" authenticaton method. >> - Implement BASIC auth using the JASPIC API, providing any necessary >> supporting code as you go. >> - Keep in mind that this Valve is going to have to support any >> JASPIC authentication module but don't worry too much about >> getting Valve architecture right first time. You can always >> refactor things later >> >> As always, if you have any questions feel free to ask them on the dev list. >> >> Mark >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
