You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Lawrence Weeks <de...@deskmedia.com> on 2000/10/07 00:11:27 UTC
Sharing sessions across contexts?
Hello,
I searched the archives and founds hints of this being possible? Does
anybody know if it is? We have a central servlet that authorizes users,
displays a menu of valid servlets, and sends the users to the selected
servlet. We're trying/hoping to use session based security, but cannot
get the session created by the authorization servlet recognized by
subsequent servlets. Any help/advice would be very appreciated.
Larry
--
Lawrence Weeks "Audaces fortuna juvat." dev@deskmedia.com
Re: Sharing sessions across contexts?
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Raimee wrote:
> Sorry for budding in Lawrence. But you have brought up a problem I am
> having and Craig has offered some interesting solutions.
>
> > As long as all these servlets run in a single webapp, you would not have
> > any problems using session based security.
> >
> > What you are describing is somewhat similar to the "single sign on" support
> > that was just added to Tomcat 4.0. It relies on webapps that use the
> > container-managed security features of the servlet 2.2/2.3 APIs, and works
> > like this: the first time the user tries to access a URI protected by a
> > security constraint, the user must log in according to the login
> > configuration of that webapp. However, their user identity is propogated
> > across all the webapps of this virtual host so the user won't be challenged
> > to log in to each webapp individually.
>
> When you say the user id is propogated accross all webapps, I infer that
> it should be availible to a servlet in any context. Though, I'm not certain how
>
> a servlet would obtain it; if it can't be bound to a session. Now, when you say
> that
> servlets running in different contexts can be 'combined' into a single context
> -
> from the point of view of the servlet container - you've lost me. Am I to infer
>
> that a Webapp can span multiple contexts? How is this achieved? Obviously
> I don't know anything about Ant. And that's probably where I am going to
> look next.
>
There is a document in the Tomcat 4.0 source distribution
(catalina/docs/singlesignon.html) that talks about how to set this up. You can
grab the binary and/or source nightly builds (or the milestone 1 release, which did
*not* have the feature we are discussing here) at <http://jakarta.apache.org>.
To clarify things a little:
* The user's security identity (that is, the value returned by
request.getUserPrincipal() or request.getRemoteUser()
is propogated across all web applications.
* Cookies must be enabled for this solution to work.
* If you are using sessions, the user still ends up with a
session *per webapp*.
The last issue is why the "single sign on" solution does not help you when your
application is trying to manage the security through sessions. SSO only helps when
you are using container-managed security.
>
> However, I have essentially an identicle problem: I require 'single sign on'
> support for two seperate webapps, and I must be able to access the userId
> from servlets in either context, once again, I'm not sure how that is achieved.
>
As above, Tomcat 4.0 will do this for you *if* you are using container-managed
security (that is, security constraints in the web.xml files).
>
> I have the added requirement of binding database connections to sessions in
> each context. The sessions can be created and then destroyed when the user
> changes contexts, but I must be able to bind new db connections once the
> sessions are re-established.
>
This part of your app will still need to work the same way it always does (although
there is no requirement that the user have only one session -- they can certainly
have a session active on all of the apps they have touched).
>
> > Doing this with application-managed security is probably going to require
> > you to write customized interceptors (Tomcat 3.x) or valves (Tomcat 4.x).
> > You might want to reconsider whether you can use either container-managed
> > security with single sign on support, as described above, or combine all
> > your logically separate applciations into one context (from the point of
> > view of the servlet container).
>
> > >
> > > Larry
> > >
>
> I have been handling authentication within my servlets. I am forced to
> use a single context for each app since I am managing user information
> with the session tracking api. Although I have been having problems
> here with one app that happens to be an applet. I have had problems
> with null sessions and strange browser behaviour affecting my applet.
>
> It seems that it's time to upgrade to Tomcat 4.x. Last time I checked
> however the DBRealm feature was tagged as Experimental. An
> attractive feature that would integrate nicely esspetially for the single sign
> on requirement.
>
Well, I wouldn't go put a production site on it yet ...
But I would really appreciate people helping to test out all the new
functionality. Look for a "milestone 2" release over the weekend that includes the
new single sign on support.
>
> Raimee
Craig
====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
Applications to Tomcat
RE: Sharing sessions across contexts?
Posted by Keith Kee <ke...@netsco.com>.
I have the same kind of problem. Before I start changing my software
architecture to make use of other technologies to achieve the single sign on
behavior, I prefer to be able to do it within the servlet arena.
> -----Original Message-----
> From: Raimee [mailto:raimee@sympatico.ca]
> Sent: Friday, October 06, 2000 9:03 PM
> To: tomcat-user@jakarta.apache.org
> Subject: Re: Sharing sessions across contexts?
>
>
> Sorry for budding in Lawrence. But you have brought up a problem I am
> having and Craig has offered some interesting solutions.
>
>
> > As long as all these servlets run in a single webapp, you would not have
> > any problems using session based security.
> >
> > What you are describing is somewhat similar to the "single sign
> on" support
> > that was just added to Tomcat 4.0. It relies on webapps that use the
> > container-managed security features of the servlet 2.2/2.3
> APIs, and works
> > like this: the first time the user tries to access a URI protected by a
> > security constraint, the user must log in according to the login
> > configuration of that webapp. However, their user identity is
> propogated
> > across all the webapps of this virtual host so the user won't
> be challenged
> > to log in to each webapp individually.
>
> When you say the user id is propogated accross all webapps, I infer that
> it should be availible to a servlet in any context. Though, I'm
> not certain how
>
> a servlet would obtain it; if it can't be bound to a session.
> Now, when you say
> that
> servlets running in different contexts can be 'combined' into a
> single context
> -
> from the point of view of the servlet container - you've lost me.
> Am I to infer
>
> that a Webapp can span multiple contexts? How is this achieved? Obviously
> I don't know anything about Ant. And that's probably where I am going to
> look next.
>
> However, I have essentially an identicle problem: I require
> 'single sign on'
> support for two seperate webapps, and I must be able to access the userId
> from servlets in either context, once again, I'm not sure how
> that is achieved.
>
> I have the added requirement of binding database connections to
> sessions in
> each context. The sessions can be created and then destroyed when the user
> changes contexts, but I must be able to bind new db connections once the
> sessions are re-established.
>
>
>
> > Doing this with application-managed security is probably going
> to require
> > you to write customized interceptors (Tomcat 3.x) or valves
> (Tomcat 4.x).
> > You might want to reconsider whether you can use either
> container-managed
> > security with single sign on support, as described above, or combine all
> > your logically separate applciations into one context (from the point of
> > view of the servlet container).
>
> > >
> > > Larry
> > >
>
> I have been handling authentication within my servlets. I am forced to
> use a single context for each app since I am managing user information
> with the session tracking api. Although I have been having problems
> here with one app that happens to be an applet. I have had problems
> with null sessions and strange browser behaviour affecting my applet.
>
> It seems that it's time to upgrade to Tomcat 4.x. Last time I checked
> however the DBRealm feature was tagged as Experimental. An
> attractive feature that would integrate nicely esspetially for
> the single sign
> on requirement.
>
> Raimee
>
>
Re: Sharing sessions across contexts?
Posted by Raimee <ra...@sympatico.ca>.
> kenneth topp wrote:
> On Fri, 6 Oct 2000, Raimee wrote:
> > When you say the user id is propogated accross all webapps, I infer
> > that it should be availible to a servlet in any context. Though, I'm
> > not certain how
> >
> > a servlet would obtain it; if it can't be bound to a session. Now,
> > when you say that servlets running in different contexts can be
> > 'combined' into a single context - from the point of view of the
> > servlet container - you've lost me. Am I to infer
>
> yes, it likely uses basic authentication (the web browsers popup). This
> is essential a politically correct cookie, that requires the users
> initial input. It also has the limitation of one URL host only.. it can
> be further restricted by a "realm" but you cannot use it two website urls:
>
> my.example.com and www.example.com
That's all I am doing. My applet cycles through http headers for JSessionId,
sets the cookie request property for the next reuqest, and my servlets manages
site resources (database) accordingly. So if container managed authentication
can be levereged to provide session management - by allowing only valid users
at sign-on and throughtout the session/cookie MaxAge, then all that is left is
to
figure out why sessions are returned null by my applet.
?????
Does setting the setRequestProperty("Cookie",JSessionId) of the applets
servletConnection
object imply that a servlets call to reequest.getSession() will return
something other than null?
?????
Could Netscape be the culprit here?
> > that a Webapp can span multiple contexts? How is this achieved?
> > Obviously I don't know anything about Ant. And that's probably where I
> > am going to look next.
>
> ant? oh, trying to dig into 4.x? heh.
It's the latest thing...
> > However, I have essentially an identicle problem: I require 'single
> > sign on' support for two seperate webapps, and I must be able to
> > access the userId from servlets in either context, once again, I'm not
> > sure how that is achieved.
>
> Perhaps some clarification should be made, are these separate webapps at
> different host urls? if they are your only choice is interceptor/valve,
> and setting a cookie (that is if they are under the same example.com
> domain). If they aren't you can still do it, but it would be more
> complex.
>
No I have a single domain and two contexts:
1host.1domain.com/context1/...webApp1 and
1host.1domain.com/context2/...webApp2
More complex than interceptors and valves? I wouldn't know. But it seems that
the complexity of tracking a userid with cookies is proportional to the
simplicity of
remembering ones own name.
> > It seems that it's time to upgrade to Tomcat 4.x. Last time I checked
> > however the DBRealm feature was tagged as Experimental. An attractive
> > feature that would integrate nicely esspetially for the single sign on
> > requirement.
>
> Yeah, but I don't think this technology is anything more then what apache
> can do for you with a more stable 3.x. Then again, any custom
> authentication code wouldn't be java ;)
htdigest works very nicely when you don't require state in your application
but
as far as I can tell, fails when you do.
Hence the need for custom authentication and session management : not only
do you need to know someone is who they say they are at login, but every time
they ask for something you need to know, and you need a way to get stuff for
them based on who they are.
> Kenneth Topp
>
> >
> > Raimee
> >
RE: Sharing sessions across contexts?
Posted by kenneth topp <ca...@prodigy.net>.
On Sun, 8 Oct 2000, Keith Kee wrote:
> Actually, it is quite different. The session id is a cookie kept at the
> server side, not the client side that you have describe.
I don't think I mentioned session id. I was trying to describe the way
http authentication works. Which, I maintain, has many properties like a
cookie.
Kenneth Topp
>
> > -----Original Message-----
> > From: kenneth topp [mailto:caught@prodigy.net]
> > Sent: Friday, October 06, 2000 9:55 PM
> > To: tomcat-user@jakarta.apache.org
> > Subject: Re: Sharing sessions across contexts?
> >
> >
> >
> > On Fri, 6 Oct 2000, Raimee wrote:
> >
> > > When you say the user id is propogated accross all webapps, I infer
> > > that it should be availible to a servlet in any context. Though, I'm
> > > not certain how
> > >
> > > a servlet would obtain it; if it can't be bound to a session. Now,
> > > when you say that servlets running in different contexts can be
> > > 'combined' into a single context - from the point of view of the
> > > servlet container - you've lost me. Am I to infer
> >
> > yes, it likely uses basic authentication (the web browsers popup). This
> > is essential a politically correct cookie, that requires the users
> > initial input.. It also has the limitation of one URL host only.. it can
> > be further restricted by a "realm" but you cannot use it two website urls:
> >
> > my.example.com and www.example.com
> >
> > >
> > > that a Webapp can span multiple contexts? How is this achieved?
> > > Obviously I don't know anything about Ant. And that's probably where I
> > > am going to look next.
> >
> > ant? oh, trying to dig into 4.x? heh.
> >
> > >
> > > However, I have essentially an identicle problem: I require 'single
> > > sign on' support for two seperate webapps, and I must be able to
> > > access the userId from servlets in either context, once again, I'm not
> > > sure how that is achieved.
> >
> > Perhaps some clarification should be made, are these separate webapps at
> > different host urls? if they are your only choice is interceptor/valve,
> > and setting a cookie (that is if they are under the same example.com
> > domain). If they aren't you can still do it, but it would be more
> > complex.
> >
> > > It seems that it's time to upgrade to Tomcat 4.x. Last time I checked
> > > however the DBRealm feature was tagged as Experimental. An attractive
> > > feature that would integrate nicely esspetially for the single sign on
> > > requirement.
> >
> > Yeah, but I don't think this technology is anything more then what apache
> > can do for you with a more stable 3.x. Then again, any custom
> > authentication code wouldn't be java ;)
> >
> > Kenneth Topp
> >
> > >
> > > Raimee
> > >
> >
> >
>
RE: Sharing sessions across contexts?
Posted by Keith Kee <ke...@netsco.com>.
Actually, it is quite different. The session id is a cookie kept at the
server side, not the client side that you have describe.
> -----Original Message-----
> From: kenneth topp [mailto:caught@prodigy.net]
> Sent: Friday, October 06, 2000 9:55 PM
> To: tomcat-user@jakarta.apache.org
> Subject: Re: Sharing sessions across contexts?
>
>
>
> On Fri, 6 Oct 2000, Raimee wrote:
>
> > When you say the user id is propogated accross all webapps, I infer
> > that it should be availible to a servlet in any context. Though, I'm
> > not certain how
> >
> > a servlet would obtain it; if it can't be bound to a session. Now,
> > when you say that servlets running in different contexts can be
> > 'combined' into a single context - from the point of view of the
> > servlet container - you've lost me. Am I to infer
>
> yes, it likely uses basic authentication (the web browsers popup). This
> is essential a politically correct cookie, that requires the users
> initial input.. It also has the limitation of one URL host only.. it can
> be further restricted by a "realm" but you cannot use it two website urls:
>
> my.example.com and www.example.com
>
> >
> > that a Webapp can span multiple contexts? How is this achieved?
> > Obviously I don't know anything about Ant. And that's probably where I
> > am going to look next.
>
> ant? oh, trying to dig into 4.x? heh.
>
> >
> > However, I have essentially an identicle problem: I require 'single
> > sign on' support for two seperate webapps, and I must be able to
> > access the userId from servlets in either context, once again, I'm not
> > sure how that is achieved.
>
> Perhaps some clarification should be made, are these separate webapps at
> different host urls? if they are your only choice is interceptor/valve,
> and setting a cookie (that is if they are under the same example.com
> domain). If they aren't you can still do it, but it would be more
> complex.
>
> > It seems that it's time to upgrade to Tomcat 4.x. Last time I checked
> > however the DBRealm feature was tagged as Experimental. An attractive
> > feature that would integrate nicely esspetially for the single sign on
> > requirement.
>
> Yeah, but I don't think this technology is anything more then what apache
> can do for you with a more stable 3.x. Then again, any custom
> authentication code wouldn't be java ;)
>
> Kenneth Topp
>
> >
> > Raimee
> >
>
>
Re: Sharing sessions across contexts?
Posted by kenneth topp <ca...@prodigy.net>.
On Fri, 6 Oct 2000, Raimee wrote:
> When you say the user id is propogated accross all webapps, I infer
> that it should be availible to a servlet in any context. Though, I'm
> not certain how
>
> a servlet would obtain it; if it can't be bound to a session. Now,
> when you say that servlets running in different contexts can be
> 'combined' into a single context - from the point of view of the
> servlet container - you've lost me. Am I to infer
yes, it likely uses basic authentication (the web browsers popup). This
is essential a politically correct cookie, that requires the users
initial input.. It also has the limitation of one URL host only.. it can
be further restricted by a "realm" but you cannot use it two website urls:
my.example.com and www.example.com
>
> that a Webapp can span multiple contexts? How is this achieved?
> Obviously I don't know anything about Ant. And that's probably where I
> am going to look next.
ant? oh, trying to dig into 4.x? heh.
>
> However, I have essentially an identicle problem: I require 'single
> sign on' support for two seperate webapps, and I must be able to
> access the userId from servlets in either context, once again, I'm not
> sure how that is achieved.
Perhaps some clarification should be made, are these separate webapps at
different host urls? if they are your only choice is interceptor/valve,
and setting a cookie (that is if they are under the same example.com
domain). If they aren't you can still do it, but it would be more
complex.
> It seems that it's time to upgrade to Tomcat 4.x. Last time I checked
> however the DBRealm feature was tagged as Experimental. An attractive
> feature that would integrate nicely esspetially for the single sign on
> requirement.
Yeah, but I don't think this technology is anything more then what apache
can do for you with a more stable 3.x. Then again, any custom
authentication code wouldn't be java ;)
Kenneth Topp
>
> Raimee
>
Re: Sharing sessions across contexts?
Posted by Raimee <ra...@sympatico.ca>.
Sorry for budding in Lawrence. But you have brought up a problem I am
having and Craig has offered some interesting solutions.
> As long as all these servlets run in a single webapp, you would not have
> any problems using session based security.
>
> What you are describing is somewhat similar to the "single sign on" support
> that was just added to Tomcat 4.0. It relies on webapps that use the
> container-managed security features of the servlet 2.2/2.3 APIs, and works
> like this: the first time the user tries to access a URI protected by a
> security constraint, the user must log in according to the login
> configuration of that webapp. However, their user identity is propogated
> across all the webapps of this virtual host so the user won't be challenged
> to log in to each webapp individually.
When you say the user id is propogated accross all webapps, I infer that
it should be availible to a servlet in any context. Though, I'm not certain how
a servlet would obtain it; if it can't be bound to a session. Now, when you say
that
servlets running in different contexts can be 'combined' into a single context
-
from the point of view of the servlet container - you've lost me. Am I to infer
that a Webapp can span multiple contexts? How is this achieved? Obviously
I don't know anything about Ant. And that's probably where I am going to
look next.
However, I have essentially an identicle problem: I require 'single sign on'
support for two seperate webapps, and I must be able to access the userId
from servlets in either context, once again, I'm not sure how that is achieved.
I have the added requirement of binding database connections to sessions in
each context. The sessions can be created and then destroyed when the user
changes contexts, but I must be able to bind new db connections once the
sessions are re-established.
> Doing this with application-managed security is probably going to require
> you to write customized interceptors (Tomcat 3.x) or valves (Tomcat 4.x).
> You might want to reconsider whether you can use either container-managed
> security with single sign on support, as described above, or combine all
> your logically separate applciations into one context (from the point of
> view of the servlet container).
> >
> > Larry
> >
I have been handling authentication within my servlets. I am forced to
use a single context for each app since I am managing user information
with the session tracking api. Although I have been having problems
here with one app that happens to be an applet. I have had problems
with null sessions and strange browser behaviour affecting my applet.
It seems that it's time to upgrade to Tomcat 4.x. Last time I checked
however the DBRealm feature was tagged as Experimental. An
attractive feature that would integrate nicely esspetially for the single sign
on requirement.
Raimee
Re: Sharing sessions across contexts?
Posted by kenneth topp <ca...@prodigy.net>.
On Fri, 6 Oct 2000, Craig R. McClanahan wrote:
> kenneth topp wrote:
>
> > this is just an implementation of http authentication of rfc2617, no?
> >
>
> I forgot to mention that Tomcat 4.0 supports all four login methods
> described in the servlet spec:
I need to read this spec!
>
> * HTTP BASIC (from RFC2617)
> * HTTP DIGEST (also from RFC2617, does not send passwords
> in cleartext across the network)
I don't think any used browsers support this yet.
> * Form-Based Login (from the servlet spec)
This sounds cool. Just read the spec. I'm not sure how you can (on
successful login) _redirect_ the user to the orginal stored URL with
request parameters intact. I'm guessing that it will always stay the same
URL. I don't think I solved redirecting browsers from request's stuffed
with POST data, and keeping them. I guess the servlet container could
always play tricks (storing the data in the server, and feeding them into
the request on success). Cannot wait to see the code for this.
> * SSL client certificate authentication
Nice.
I'm still struggling with how to merge these authentication systems with
the simple authorization schemes they tend to insist upon (ie: user can or
cannot do, based on the name or their group).
Well, anyway, thanks for the update!
Kenneth Topp
RE: Sharing sessions across contexts?
Posted by Scott Sanders <sc...@totalsync.com>.
> > Can the Form-based Login be active content from a servlet
> (as long as it
> > follows the spec of course), or is it only dynamic. Just
> asking because of
> > the need to present the screen in both HTML and WML.
> >
>
> The login form itself can be either a servlet or a JSP page, so it can
> definitely be dynamically created. (Static HTML pages also
> work, but that will
> not help in your scenario where you want different output to different
> clients) The primary requirement that may matter more is
> that the login form
> has to be able to do an HTTP POST to a specific action
> ("j_security_check")
> with specific field names ("j_username" and "j_password").
> If your WML-based
> clients can do that, you should be fine.
>
> By the way, form-based login (for individual apps, not the
> "single sign on"
> support) is available in Tomcat 3.2 as well.
>
Thanks, Craig.
I was aware it was available in 3.2, but even though I don't need the single
signon feature, I absolutely _WANT_ (need) the filtering capabilities. It
is the design pattern that I was trying to implement on my own, so now I can
try and help T4 along. ;-)
Just need to catch up...
Re: Sharing sessions across contexts?
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Scott Sanders wrote:
> Can the Form-based Login be active content from a servlet (as long as it
> follows the spec of course), or is it only dynamic. Just asking because of
> the need to present the screen in both HTML and WML.
>
The login form itself can be either a servlet or a JSP page, so it can
definitely be dynamically created. (Static HTML pages also work, but that will
not help in your scenario where you want different output to different
clients) The primary requirement that may matter more is that the login form
has to be able to do an HTTP POST to a specific action ("j_security_check")
with specific field names ("j_username" and "j_password"). If your WML-based
clients can do that, you should be fine.
By the way, form-based login (for individual apps, not the "single sign on"
support) is available in Tomcat 3.2 as well.
>
> Thanks
> Scott Sanders
>
Craig
>
> -----Original Message-----
> From: Craig R. McClanahan [mailto:Craig.McClanahan@eng.sun.com]
> Sent: Friday, October 06, 2000 7:50 PM
> To: tomcat-user@jakarta.apache.org
> Subject: Re: Sharing sessions across contexts?
>
> kenneth topp wrote:
>
> > this is just an implementation of http authentication of rfc2617, no?
> >
>
> I forgot to mention that Tomcat 4.0 supports all four login methods
> described in
> the servlet spec:
>
> * HTTP BASIC (from RFC2617)
> * HTTP DIGEST (also from RFC2617, does not send passwords
> in cleartext across the network)
> * Form-Based Login (from the servlet spec)
> * SSL client certificate authentication
>
> >
> >
> > Kenneth Topp
>
> Craig McClanahan
>
> ====================
> See you at ApacheCon Europe <http://www.apachecon.com>!
> Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
> Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
> Applications to Tomcat
--
====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
Applications to Tomcat
RE: Sharing sessions across contexts?
Posted by Scott Sanders <sc...@totalsync.com>.
Can the Form-based Login be active content from a servlet (as long as it
follows the spec of course), or is it only dynamic. Just asking because of
the need to present the screen in both HTML and WML.
Thanks
Scott Sanders
-----Original Message-----
From: Craig R. McClanahan [mailto:Craig.McClanahan@eng.sun.com]
Sent: Friday, October 06, 2000 7:50 PM
To: tomcat-user@jakarta.apache.org
Subject: Re: Sharing sessions across contexts?
kenneth topp wrote:
> this is just an implementation of http authentication of rfc2617, no?
>
I forgot to mention that Tomcat 4.0 supports all four login methods
described in
the servlet spec:
* HTTP BASIC (from RFC2617)
* HTTP DIGEST (also from RFC2617, does not send passwords
in cleartext across the network)
* Form-Based Login (from the servlet spec)
* SSL client certificate authentication
>
>
> Kenneth Topp
Craig McClanahan
====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
Applications to Tomcat
Re: Sharing sessions across contexts?
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
kenneth topp wrote:
> this is just an implementation of http authentication of rfc2617, no?
>
I forgot to mention that Tomcat 4.0 supports all four login methods described in
the servlet spec:
* HTTP BASIC (from RFC2617)
* HTTP DIGEST (also from RFC2617, does not send passwords
in cleartext across the network)
* Form-Based Login (from the servlet spec)
* SSL client certificate authentication
>
>
> Kenneth Topp
Craig McClanahan
====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
Applications to Tomcat
Re: Sharing sessions across contexts?
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
kenneth topp wrote:
> On Fri, 6 Oct 2000, Craig R. McClanahan wrote:
>
> > What you are describing is somewhat similar to the "single sign on" support
> > that was just added to Tomcat 4.0. It relies on webapps that use the
> > container-managed security features of the servlet 2.2/2.3 APIs, and works
> > like this: the first time the user tries to access a URI protected by a
> > security constraint, the user must log in according to the login
> > configuration of that webapp. However, their user identity is propogated
> > across all the webapps of this virtual host so the user won't be challenged
> > to log in to each webapp individually.
>
> this is just an implementation of http authentication of rfc2617, no?
>
Not only that.
You set up container-managed security for each of the applications in your
web.xml file, following the standard capabilities described by the servlet 2.2
and 2.3 specs. The first time that your user accesses a portion of the webapp
protected by a security constraint, they will be challenged to log on according
to whatever login configuration you have set for that app. The thing that single
sign on (SSO) does for you is save having to have the same user log on again for
each of the other apps.
>
> Is the security constraint going to be customizable, like apache
> (mod_auth_*)?
>
There are several levels of customization available:
* The container managed security mechanism lets you declare
security constraints over individual URLs, over "subdirectories"
of your webapps URL space, or even on filename extensions
(such as "protect access to every JSP page).
* Attached to a security constraint, you get to declare what roles
(think "groups" if you are used to Apache) have access to the
URLs protected by this constraint.
How a servlet container looks up users and their roles is *not* standardized.
However, Tomcat 4.0 provides an API (pretty similar to the one in Tomcat 3.x) to
define your own Realm. Two Realms are already provided (one that reads the
"conf/tomcat-users.xml" file, and one that connects to a database), but more can
easily be created.
>
> Kenneth Topp
Craig McClanahan
====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
Applications to Tomcat
Re: Sharing sessions across contexts?
Posted by kenneth topp <ca...@prodigy.net>.
On Fri, 6 Oct 2000, Craig R. McClanahan wrote:
> What you are describing is somewhat similar to the "single sign on" support
> that was just added to Tomcat 4.0. It relies on webapps that use the
> container-managed security features of the servlet 2.2/2.3 APIs, and works
> like this: the first time the user tries to access a URI protected by a
> security constraint, the user must log in according to the login
> configuration of that webapp. However, their user identity is propogated
> across all the webapps of this virtual host so the user won't be challenged
> to log in to each webapp individually.
this is just an implementation of http authentication of rfc2617, no?
Is the security constraint going to be customizable, like apache
(mod_auth_*)?
Kenneth Topp
Re: Sharing sessions across contexts?
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Lawrence Weeks wrote:
> Hello,
>
> I searched the archives and founds hints of this being possible?
Sharing sessions across contexts is expressly forbidden by the servlet
spec.
There are some fundamental security and technical hurdles to doing things
any other way. (Consider, for instance, the fact that each context has
their own classloader -- so a session attribute inserted from one webapp
would not be usable in another webapp).
> Does
> anybody know if it is? We have a central servlet that authorizes users,
> displays a menu of valid servlets, and sends the users to the selected
> servlet. We're trying/hoping to use session based security, but cannot
> get the session created by the authorization servlet recognized by
> subsequent servlets. Any help/advice would be very appreciated.
>
As long as all these servlets run in a single webapp, you would not have
any problems using session based security.
What you are describing is somewhat similar to the "single sign on" support
that was just added to Tomcat 4.0. It relies on webapps that use the
container-managed security features of the servlet 2.2/2.3 APIs, and works
like this: the first time the user tries to access a URI protected by a
security constraint, the user must log in according to the login
configuration of that webapp. However, their user identity is propogated
across all the webapps of this virtual host so the user won't be challenged
to log in to each webapp individually.
Doing this with application-managed security is probably going to require
you to write customized interceptors (Tomcat 3.x) or valves (Tomcat 4.x).
You might want to reconsider whether you can use either container-managed
security with single sign on support, as described above, or combine all
your logically separate applciations into one context (from the point of
view of the servlet container).
>
> Larry
>
Craig McClanahan
====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
Applications to Tomcat