You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by David Jencks <da...@yahoo.com> on 2009/04/05 00:36:11 UTC
Re: GSOC: Convert current Tomcat valves to Servlet Filters, I revised my project plan based on the comments of Mark
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: GSOC: Convert current Tomcat valves to Servlet Filters, I revised
my project plan based on the comments of Mark
Posted by Xie Xiaodong <xx...@gmail.com>.
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 <xx...@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 <da...@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>
>
> --
> Sincerely yours and Best Regards,
> Xie Xiaodong
>
--
Sincerely yours and Best Regards,
Xie Xiaodong
Re: GSOC: Convert current Tomcat valves to Servlet Filters, I revised
my project plan based on the comments of Mark
Posted by Xie Xiaodong <xx...@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 <da...@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
--
Sincerely yours and Best Regards,
Xie Xiaodong