What sort of application server are the users "authenticated" in? I take it at it is not WebSphere. You might look at the Trust Association interceptors. If configured, the trust association code gets invoked when a websphere protected web resource is invoked for an unauthenticated user. It passes the http request to the trust code and allows you to tell websphere that this person is already authenticated and his userid is xxx. The default config assumes that you are using IBM's WebSeal product, but you can write your own intercepter. It might be kind of tricky to code, but you could retrieve the "roles" from the request and save them somewhere so that when websphere invokes the CustomRegistry calls to retrieve the groups for the user, it returns the "roles" that you had saved off for that user. I would think that it would be safer though if your app had access to whatever data store that the original "logon" app does and look up the roles yourself rather than passing them in the http request.
John Zerbe - Mellon Financial Corp. Information Technology Solutions - Middleware Team Phone: 412-234-1048 E-Mail:[EMAIL PROTECTED] AIM: 153-1315 -----Original Message----- From: alexandre bord [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 27, 2002 8:02 AM To: [EMAIL PROTECTED] Subject: Re: Unusual (?) security management Hello, I totally agree with you and the redbooks are on my desktop ! The problem is that we can't manage the authentication process. As i explained, users are authenticated before our "login.jsp" is called, they even may be authneticated before our WAS is started. The only things we get are : the username and its roles. And we would like to let Websphere think (in any way) that they are really authenticated. We thought we could implement the CustomRegistry interface just saying "ok" when the isPasswordValid method is called But we can not retrieve Roles. So ... Any further idea is welcome ! We use Wesphere AE 4.0.3 (Solaris). Best regards. Alexandre Zerbe John W wrote: >What version of websphere are you using? (eg: Single Server Edition or Advanced >Edition version 3.5, or 4.0) >If you are using Advanced edition, you can configure "single signon" for a web domain. >1) you use an LDAP server for authentication and assign the userids to groups for >role mapping. >2) you configure the single signon domain for something like ".mycompany.com". >3) your users login to your "gateway" application. (eg mainsite.mycompany.com) >4) WebSphere generates a LTPAToken cookie with the .mycompany.com set as the cookie >domain. (this contains your encrypted security credentials) >5) your app does a sendredirect() to something like >https://app1.mycompany.com/mainservlet >6) the LTPAToken flows to the new servlet. >7) since websphere honors the LTPAToken, your security context is set up for you. ie >websphere knows what your userid is and what ldap groups you belong to. Since the >LTPAToken is encrypted, your not sending your user and roles as http parameters >through the network, hence they can't be easily forged. > >IBM has websphere "handbooks" for versions 3.5 and 4.0 published as "redbooks". > >John Zerbe - Mellon Financial Corp. >Information Technology Solutions - Middleware Team >Phone: 412-234-1048 E-Mail:[EMAIL PROTECTED] >AIM: 153-1315 > > >-----Original Message----- >From: alexandre bord [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, November 27, 2002 4:09 AM >To: [EMAIL PROTECTED] >Subject: Unusual (?) security management > > >Hello, >We are developping an J2EE application which uses Servlets / JSP and EJBs >The login process is not a classic (?) one : all users login in a >WebApp. They are showed the apps they are allowed to use. When they >choose one app, they are forwarded to the Login.jsp of the specific web >application (other Web server). The HTTP parameters are the username and >the user roles. > >We would like to make our Application Server (Websphere) be aware of >this, so we could propagate on the EJB layer. >We develop only our WebApp, and so can not modify the login process, nor >could retrieve user roles in any other way than the HTTP parameters to >Login.jsp > >Awaiting for your ideas, >Best regard >Alexandre > >___________________________________________________________________________ >To unsubscribe, send email to [EMAIL PROTECTED] and include in the body >of the message "signoff SERVLET-INTEREST". > >Archives: http://archives.java.sun.com/archives/servlet-interest.html >Resources: http://java.sun.com/products/servlet/external-resources.html >LISTSERV Help: http://www.lsoft.com/manuals/user/user.html > > >DISCLAIMER: >The information contained in this e-mail may be confidential and is intended solely >for the use of the named addressee. Access, copying or re-use of the e-mail or any >information contained therein by any other person is not authorized. If you are not >the intended recipient please notify us immediately by returning the e-mail to the >originator. > >___________________________________________________________________________ >To unsubscribe, send email to [EMAIL PROTECTED] and include in the body >of the message "signoff SERVLET-INTEREST". > >Archives: http://archives.java.sun.com/archives/servlet-interest.html >Resources: http://java.sun.com/products/servlet/external-resources.html >LISTSERV Help: http://www.lsoft.com/manuals/user/user.html > > > > ___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST". Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html DISCLAIMER: The information contained in this e-mail may be confidential and is intended solely for the use of the named addressee. Access, copying or re-use of the e-mail or any information contained therein by any other person is not authorized. If you are not the intended recipient please notify us immediately by returning the e-mail to the originator. ___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST". Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
