Skip to Content.
Sympa Menu

grouper-users - RE: [grouper-users] Error 403, but logged in anyway

Subject: Grouper Users - Open Discussion List

List archive

RE: [grouper-users] Error 403, but logged in anyway


Chronological Thread 
  • From: "GW Brown, Information Systems and Computing" <>
  • To: Chris Hyzer <>,
  • Cc: Grouper Users Mailing List <>
  • Subject: RE: [grouper-users] Error 403, but logged in anyway
  • Date: Thu, 19 Mar 2009 15:10:10 +0000
--On 19 March 2009 10:57 -0400 Chris Hyzer
<>
wrote:

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...
Should be a choice. I did it this way to make it easier to use alternative schemes - which I expected to be implemented at the Apache level. I wasn't really trying to use the role for security but it is misleading. We could just set role to * and document it.

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...
That is all configurable / customisable but it's nice, when you are getting started, to have a splash screen which shows something is working before you struggle with authentication

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




----------------------
GW Brown, Information Systems and Computing


Archive powered by MHonArc 2.6.16.

Top of Page