Although the specification does not cover whether the *ServerAuthModule *should
be stateful or stateless, I think we'd better keep it stateless for
scalability.





2009/4/5 Xie Xiaodong <xxd82...@gmail.com>

> Thank you, David.
>
> After having a glance at JSR-196 Specification, the intuitive of design
> decision is to implement the built in auth methods (BASIC, DIGEST,  FORM,
> CLIENT_CERT) of Tomcat Valve with ServerAuthModule. And I agreed the
> difficulty of implementing the auth function into filter you mentioned in
> previous mail, so I decided to implementing so independent structure
> consistent with JSR-196. As this specification specified, the API is
> something like this:
>
>
>    1. AuthConfigFactory factory = AuthConfigFactory.getFactory();
>    2. AuthConfigProvider provider =
>    factory.getConfigProvider(layer,appID,listener);
>    3. ServerAuthConfig config =
>    provider.getServerAuthConfig(layer,appID,cbh)
>    4. String authContextID = config.getAuthContextID(messageInfo);
>    5. ServerAuthContext context =
>    config.getAuthContext(authContextID,subject,properties);
>    6. context.secureResponse(messageInfo,subject);
>
> And the functionality of formal Tomcat valve will be refactored into
> ServerAuthModule which will be encapsulated by ServerAuthContext.
>
> I'll check where caching could be used for the efficiency.
>
> And I think it is import to go with the specification since it will allow
> other developer to contribute their own code, and our code could also be
> used by others.
>
> ps: I greatly agree with the structure you give in previous mail:
>
> check user data constraints
> Status status = validate request
> if (status == success) {
>  check web resource constraints
>  process request
>  secure response
> }
>
>
>
>
>
>
> 2009/4/5 David Jencks <david_jen...@yahoo.com>
>
>
>> On Apr 4, 2009, at 3:01 PM, Xie Xiaodong wrote:
>>
>>  Hello, Dear All,
>>>  First, thank you very much for you valuable comments, Mark.
>>>  I've revised my project plan based on the comments of Mark, since I
>>> could
>>> not edit my proposal any longer, I wrote the revised version of project
>>> plan
>>> in a comment of my proposal, you can find it for certain by searching the
>>> "Show Student Proposal" page with "xiaodong xie wrote". Sorry for this
>>> inconvenience.
>>>  I am now getting myself familiar with the Servlet Container Profile of
>>> JSR-196 in order to move the Authentication funcationality of valve into
>>> some independent structure consistence with JSR-196. This part will be
>>> added
>>> into my project proposal in some comment later.
>>>  Any more comments, feedback and criticism to my proposal are welcomed.
>>>
>>
>> While it is possible to implement the built in auth methods (BASIC,
>> DIGEST,  FORM, CLIENT_CERT) as jaspi auth modules it's not as efficient as
>> having a more tomcat-specific auth method.  The important part is really
>> having a validate request method called before the web resource constraint
>> check and a secure response method called after the request has been
>> processed.  There are a lot of opportunities for improved caching if you
>> don't follow the jaspi model exactly, mostly by letting the authenticator
>> return the user identity rather than passing in a brand new Subject instance
>> for each request.
>>
>> I recommend that the valve or filter look something like this:
>>
>> check user data constraints
>> Status status = validate request
>> if (status == success) {
>>  check web resource constraints
>>  process request
>>  secure response
>> }
>> //otherwise the validate request  call will have set up an appropriate
>> response to continue the authentication message exchange
>>
>> "validate request" and "secure response" are delegated to some kind of
>> authenticator similar to but more efficient than a jaspi auth context
>>
>> constraint checking can either be (abstract) methods on the (base) valve
>> or delegated to some other object.  The point here is to easily support both
>> constraint based checking (as done in tomcat today) and jacc based
>> permission checking (as done in geronimo and presumably other javaee
>> integrations such as jboss)
>>
>> thanks
>> david jencks
>>
>>
>>>
>>> --
>>> Sincerely yours and Best Regards,
>>> Xie Xiaodong
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>
>
>
> --
> Sincerely yours and Best Regards,
> Xie Xiaodong
>



-- 
Sincerely yours and Best Regards,
Xie Xiaodong

Reply via email to