Morten, I missed the orginal post but noticed in a later message you rejected the Tomcat role-based model as "too coarse grained". If you use a JDBC based security model you can assign more than one role to a user. I have used this to good effect with the following header code in controlled pages:
<%@ page import="java.sql.*" %> <%@ taglib uri="http://jakarta.apache.org/taglibs/request-1.0"; prefix="req" %> <%@ taglib uri="http://jakarta.apache.org/taglibs/response-1.0"; prefix="rsp" %> <% Class.forName("org.gjt.mm.mysql.Driver"); %> <req:request id="rq"/> <% boolean validRole = false; %> <req:isUserInRole role="leader"> <% validRole = true; %> </req:isUserInRole> <% if (!validRole) { System.out.println("access is not allowed"); %> <rsp:sendError error="SC_FORBIDDEN" reset="true"/> <rsp:skipPage/> <% } %> <HTML> .... insert the rest of your page here. This page is restricted to users who have been assigned both the member and the leader roles. The requirement for assignment to the member role comes from your web app's web.xml file thus <security-constraint> <web-resource-collection> <web-resource-name>ScoutGroup-Secure</web-resource-name> <url-pattern>/members/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>member</role-name> </auth-constraint> <user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint> </security-constraint> It is necessary for every user to have a "member" role assigned in order to reach the members' section (that is one role per web app to allow access in the first place) but, having been permitted to access the members' pages, you can further control access to pages within that area by performing your own role checks within each page. Murray -----Original Message----- From: Morten Andersen [mailto:[EMAIL PROTECTED] Sent: Friday, 26 September 2003 20:33 To: Tomcat Users List Subject: Re: Authentication - based on request parameters Here is my requirements for the security mechanism: The whole thing is about making secured rooms for groups of user. 1) It should be possible to make new sites / groups while the application is running. 2) The sites has members, and only these should be allowed to do some of the restricted requests. 3) Some sites may be totally open, so that everyone can do anything without logging in. 4) All of this is decided while the application is running. 5) One user may be administrator of 1 group and not allowed to do anything in another. So for instance the request: TomcatServer:8080/MyApp/restrictedRequest.action?site=closedSite would result in that the user is required to login using a login-screen, because closedSite is defined as closed. while the request: TomcatServer:8080/MyApp/restrictedRequest.action?site=openSite Would not result in that the user has to login, because the openSite is defined as total open. At 11:06 26-09-2003 +0100, you wrote: >The problem is that your model does not seem to be based on a "secret" and >site names don't have a lot of entropy. I don't know enough about your >model to give you examples of possible attacks, but it seems to be similar >to an access control model where you ask to people to enter their user ID >but no password. Saying "Oh, the client has to know a valid user name to >get in" would not be enough to make this a secure model. Why? knowing my hotmail address doesn't make it possible for other than me to login to my hotmail account. >If you store the >remote site information in the Session, this information is stored-server >side and a client never even gets the chance to have a go at circumventing >it. > >The role model can be made to work. You have a list of clients, or sites, >and you assign them roles. You create a table of role-to-permissions or >simply declare the required roles in your JSP. Then in your pages make the >following access check: > >// This gives "MyApp/saveEditedPage.action" in your original example; you >may also use >// getServletPath() to give you "saveEditedPage.action" >String requestURI = request.getRequestURI(); >// Implement this method yourself >String[] permittedRoles = getPermittedRoles(requestURI); >boolean accessAllowed = false; >for (int i = 0; i < permittedRoles.length; i++) >{ > if (request.isUserInRole(permittedRoles[i])) > { > accessAllowed = true; > break; > } >} > >This is simply an example, of course, and I don't know whether such a scheme >would work for you. > >----- Original Message ----- >From: "Morten Andersen" <[EMAIL PROTECTED]> >To: "Tomcat Users List" <[EMAIL PROTECTED]> >Sent: Friday, September 26, 2003 10:33 AM >Subject: Re: Authentication - based on request parameters > > > > Why is that a security-issue? > > I wan't the user to enter the site by cliking on a link or whatever, so > > that the user enters the site using that request. It should be OK, that >the > > user tryes to go to a restricted page by writing > > blabla:8080/MyApp/restrictedRequest.action?site=JustAGuess > > > > But if that is done and the user has not got rights to do it, then he is > > being rejected... > > > > Regards > > > > Morten Andersen > > > > PS: I did consider the role-based model form tomcat, but that is > > coarse-grained, in the sense that it is based on 1 role for one web-app, > > and that is not suficient. > > > > > > >Something else that occurs to me is that your security model appears to > > >depend on a GET parameter in the request ("?site=MySite"). A client >could > > >easily change this value to circumvent your security. A better model is > > >that your logon page sets a value in the Session object to identify the > > >user. Then the security depends on a very long, random session ID and it >is > > >vanishingly unlikely that a client will be able to change this ID (either >in > > >a URL or a cookie) and, by chance, hit on a valid session ID belonging to > > >another user. > > > > > > > > > > > >--------------------------------------------------------------------- > > >To unsubscribe, e-mail: [EMAIL PROTECTED] > > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > Morten Andersen > > Master of applied mathematics and computer science > > Amanuensis (in e-learning) > > > > The Maersk Institute of Production technology at Southern Danish >University > > www.mip.sdu.dk > > Campusvej 55 > > DK-5230 Odense M > > Denmark > > +45 6550-3654 > > +45 6171-1103 > > Jabber id: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] Morten Andersen Master of applied mathematics and computer science Amanuensis (in e-learning) The Maersk Institute of Production technology at Southern Danish University www.mip.sdu.dk Campusvej 55 DK-5230 Odense M Denmark +45 6550-3654 +45 6171-1103 Jabber id: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
