Tomcat does have a realm in different level(Engine,Host,Webapp) for security. Check http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html
2006/1/20, Jack <[EMAIL PROTECTED]>: > > > In order to add a new user to a web-app, since specification 2.4 doesn't > cover this, web-app might have to take care of this. User information will > be used by web-app anyway, the web-app keeps many information about the > user. Keep its password is not difficult at all, and it is easier for the > web-app to change password for the user. In case the user uses a > certificate, the web-app might also use the certificate anyway. So the > UserManager will be used by both the web-app Container & the web-app. > > > > There are 3 types user contexts: > > 1. Engine user context (tomcat-userx.xml, should not mix up with host & > web-app user context. At present, they all mixed up.) > > 2. Host user context (Users defined in a host user context will be > available > to all web-apps in this host.) > > 3. Web-app user context > > > > Under the Engine element, add a Users element (EngineUserContext). Its > content is the content of tomcat-users.xml, and tomcat-users.xml could be > eliminate, or an attribute in Users link to tomcat-users.xml. > > Under each Host element, there could be a Users element (HostUserContext), > too. > > In the context.xml for each web-app, there could be a Users element > (WebAppUserContext), too. > > > > In Host Users & web-app users elements, the possible attributes are: > > > > scope=host|engine whether users information available to other context. > "host" is the default value. > > useHost=yes|no Using users defined in the host context. default: yes > > useOtherWebApp=yes|no Using users defined in other web-app exposed to > the > same host. default: yes > > useOtherHost=yes|no Using users defined in other host exposed to the > same > engine. default: no > > clientAuth > > keystoreFile > > keystorePass > > keystoreType > > truststoreFile > > truststorePass > > truststoreType > > > > The last 6 attributes of Connector element should become attributes of > Users > elements since they are all UserContext properties. > > > > "clientAuth" is configed in the login-config element in web.xml. If the > client is requesting a server resource that requires client > authentication, > the server requests the client's certificate. However, it could also be > put > on Users element. > > > > Single Signon > > At present, single signon is done with a valve. > > > > For a user crosses a web-app (1) to another web-app (2) to access a > constrained resource, the authorizer(Realm) will call the UserManager > whether the user has a role for the resource. And the UserManager will > consult the user context of the web-app 2 to check whether it accept users > from web-app 1. If yes, and the user is authenticated, then the container > doesn't have to ask the user do authentication again. > > > > This will be more logic than the original implementation with valve. > > > [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- ---------------------------------------- Terry(Xiaochao) Zhou
