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]
