GSOC: Convert current Tomcat valves to Servlet Filters, I revised my project plan based on the comments of Mark
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. -- 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
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
Re: GSOC: Convert current Tomcat valves to Servlet Filters, I revised my project plan based on the comments of Mark
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
Re: GSOC: Convert current Tomcat valves to Servlet Filters, I revised my project plan based on the comments of Mark
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
