Grouper Users - Open Discussion List

[Chris Hyzer <>]

Can this be a security problem, and all URLs should be protected which need 
protection, otherwise you could get in without the proper role, right?  
Granted in some schools its not an issue since role isn’t important, it’s the 
authentication...

I wouldn’t mind if there wasn’t an anonymous splash screen, just so things 
are simpler and more secure.  We do that at Penn, and the current splash 
screen says "Start" instead of "Login" or whatever the default text is...

Thanks,
Chris

> -----Original Message-----
> From: GW Brown, Information Systems and Computing
> [mailto:]
> Sent: Thursday, March 19, 2009 9:51 AM
> To: 
> 
> Cc: Grouper Users Mailing List
> Subject: Re: [grouper-users] Error 403, but logged in anyway
> 
> Hi Loris,
> 
> when you attempt to access /grouper-dev/ do you see the Grouper splash
> screen with a login link or are you prompted for credentials
> immediately?
> 
> Do you map users to the grouper_user role?
> 
> What might be happening is that you successfully authenticate against
> LDAP
> but are not assigned the grouper_user role required by the security
> constraint in the web.xml. The security constraint only applies to
> login.do. After that we depend on a session variable. So authentication
> works, the role check fails, on going to /grouper-dev/ again the
> grouper ui
> sees a 'remoteUser' and creates a session.
> 
> You could try replacing the auth-constraint role-name with *
> <auth-constraint>
>   <role-name>*</role-name>
> </auth-constraint>
> 
> otherwise you can have multiple role-name elements to match appropriate
> roles in LDAP.
> 
> Gary
> 
> 
> 
> 
> --On 19 March 2009 14:17 +0100 Loris Bennett 
> <loris.bennett@fu-
> berlin.de>
> wrote:
> 
> > Hi Gary,
> >
> > Authentication is done via META-INF/context.xml:
> >
> >         <Context path="/grouper"
> >                  docBase="grouper"
> >                  debug="0"
> >                  privileged="false"
> >                  reloadable="false"
> >                  swallowOutput="true">
> >           <Realm  className="org.apache.catalina.realm.JNDIRealm"
> >                   debug="99"
> >                   connectionURL="ldaps://host1.dept.fu-
> berlin.de:1234"
> >                   alternateURL="ldaps://host2.dept.fu-berlin.de:1234"
> >                   userPattern="uid={0},ou=dept,o=fu-berlin,c=de"
> >                   roleBase="ou=grouper,o=fu-berlin,c=de"
> >                   roleSubtree="true"
> >                   roleSearch="(uniquemember={0})"
> >                   roleName="cn"
> >                   connectionName="cn=manager,o=fu-berlin,c=de"
> >                   connectionPassword="xxx"/>
> >         </Context>
> >
> > Cheers,
> >
> > Loris
> >
> >
> > On Thu, 2009-03-19 at 13:02 +0000, GW Brown, Information Systems and
> > Computing wrote:
> >> Hi Loris,
> >>
> >> How is the LDAP authentication achieved?
> >>
> >> Gary
> >>
> >> --On 19 March 2009 13:53 +0100 Loris Bennett
> >> <>
> >>   wrote:
> >>
> >> > Hi Gary,
> >> >
> >> > I am not using Apache - just Tomcat on its own.
> >> >
> >> > Cheers
> >> >
> >> > Loris
> >> > On Thu, 2009-03-19 at 11:24 +0000, GW Brown, Information Systems
> and
> >> > Computing wrote:
> >> >> Hi Loris,
> >> >>
> >> >> Have you got Apache in front of Tomcat - and is it doing the
> >> >> authentication? If so does it blanket protect grouper-dev?
> Otherwise
> >> >> are you using a servlet filter?
> >> >>
> >> >> If you are using Apache can you isolate and post the relevant
> section
> >> >> of the access log?
> >> >>
> >> >> In the web.xml there is a security constraint:
> >> >> <security-constraint>
> >> >>     <web-resource-collection>
> >> >>       <web-resource-name>Tomcat login</web-resource-name>
> >> >>       <url-pattern>/login.do</url-pattern>
> >> >>     </web-resource-collection>
> >> >>     <auth-constraint>
> >> >>        <!-- NOTE:  This role is not present in the default users
> file
> >> >>        --> <role-name>grouper_user</role-name>
> >> >>     </auth-constraint>
> >> >>   </security-constraint>
> >> >>
> >> >> Which may not be necessary if the authentication is through
> Apache.
> >> >>
> >> >> Thanks,
> >> >>
> >> >> Gary
> >> >>
> >> >> --On 19 March 2009 11:34 +0100 Loris Bennett
> >> >> <>
> >> >>   wrote:
> >> >>
> >> >> > Hi Gary,
> >> >> >
> >> >> > My webapp is actually "grouper-dev" - "grouper" just comes from
> me
> >> >> > having tweaked the logfile in a half-baked manner.
> >> >> >
> >> >> > I am authenticating against an LDAP server.
> >> >> >
> >> >> > Cheers,
> >> >> >
> >> >> > Loris
> >> >> >
> >> >> > On Thu, 2009-03-19 at 09:07 +0000, GW Brown, Information
> Systems and
> >> >> > Computing wrote:
> >> >> >> Hi Loris,
> >> >> >>
> >> >> >> Looking at the log I see:
> >> >> >>
> >> >> >>   Caught '403' for /grouper-dev/login.do
> >> >> >>
> >> >> >> but the urls you gave /grouper/login.do. Is there actually a
> >> >> >> difference? If  so doing a clean build may help.
> >> >> >>
> >> >> >> What authentication are you using?
> >> >> >>
> >> >> >> Gary
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> --On 19 March 2009 09:37 +0100 Loris Bennett
> >> >> >> <>
> >> >> >>   wrote:
> >> >> >>
> >> >> >> > Hi,
> >> >> >> >
> >> >> >> > Most, but not all, users get error 403 on logging into
> grouper.
> >> >> >> > The URL displayed is
> >> >> >> >
> >> >> >> >         https://host.fu-berlin.de:1234/grouper/login.do
> >> >> >> >
> >> >> >> > If they then delete the "login.do" bit of the URL, they get
> >> >> >> > redirected to
> >> >> >> >
> >> >> >> >         https://host.fu-berlin.de:1234/grouper/home.do
> >> >> >> >
> >> >> >> > and everything is fine. A log extract for the login is
> attached.
> >> >> >> >
> >> >> >> > Cheers
> >> >> >> >
> >> >> >> > Loris
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> > --
> >> >> >> > Dr. Loris Bennett (Mr.)
> >> >> >> > Freie Universität Berlin
> >> >> >> > ZEDAT - Zentraleinrichtung für Datenverarbeitung / Computer
> >> >> >> > Center Compute & Media Service
> >> >> >> > Fabeckstr. 32, Room 221
> >> >> >> > D-14195 Berlin
> >> >> >> > Tel ++49 30 838 51024
> >> >> >> > Fax ++49 30 838 56721
> >> >> >> > Email 
> >> >> >> > 
> >> >> >> > Web www.zedat.fu-berlin.de
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> ----------------------
> >> >> >> GW Brown, Information Systems and Computing
> >> >> >> 
> >> >> > --
> >> >> > Dr. Loris Bennett (Mr.)
> >> >> > Freie Universität Berlin
> >> >> > ZEDAT - Zentraleinrichtung für Datenverarbeitung / Computer
> Center
> >> >> > Compute & Media Service
> >> >> > Fabeckstr. 32, Room 221
> >> >> > D-14195 Berlin
> >> >> > Tel ++49 30 838 51024
> >> >> > Fax ++49 30 838 56721
> >> >> > Email 
> >> >> > 
> >> >> > Web www.zedat.fu-berlin.de
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> ----------------------
> >> >> GW Brown, Information Systems and Computing
> >> >> 
> >> > --
> >> > Dr. Loris Bennett (Mr.)
> >> > Freie Universität Berlin
> >> > ZEDAT - Zentraleinrichtung für Datenverarbeitung / Computer Center
> >> > Compute & Media Service
> >> > Fabeckstr. 32, Room 221
> >> > D-14195 Berlin
> >> > Tel ++49 30 838 51024
> >> > Fax ++49 30 838 56721
> >> > Email 
> >> > 
> >> > Web www.zedat.fu-berlin.de
> >> >
> >>
> >>
> >>
> >> ----------------------
> >> GW Brown, Information Systems and Computing
> >> 
> > --
> > Dr. Loris Bennett (Mr.)
> > Freie Universität Berlin
> > ZEDAT - Zentraleinrichtung für Datenverarbeitung / Computer Center
> > Compute & Media Service
> > Fabeckstr. 32, Room 221
> > D-14195 Berlin
> > Tel ++49 30 838 51024
> > Fax ++49 30 838 56721
> > Email 
> > 
> > Web www.zedat.fu-berlin.de
> >
> 
> 
> 
> ----------------------
> GW Brown, Information Systems and Computing
>