Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] CAS authentication for Grouper

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] CAS authentication for Grouper


Chronological Thread 
  • From: Baron Fujimoto <>
  • To: "GW Brown, Information Systems and Computing" <>
  • Cc:
  • Subject: Re: [grouper-users] CAS authentication for Grouper
  • Date: Fri, 14 Oct 2011 16:09:33 -1000

On Thu, Oct 13, 2011 at 09:17:28PM +0100, GW Brown, Information Systems and
Computing wrote:
: --On 12 October 2011 08:17 -1000 Baron Fujimoto
<>
wrote:
:
: >I'm trying to set up CAS authentication for Grouper 2.0 using Cal Poly's
: >contributed page as a reference:
: >
: ><https://spaces.internet2.edu/display/Grouper/Implementing+CAS+Authentica
: >tion+for+Grouper>
: >
: >I've run into a series of problems, though I'm not sure which if any are
: >dependent on others. (Apologies for the length.)
: >
: >I'm getting the following exception reported in my browser when I try
: >to access the UI:
: >
: >java.lang.IllegalStateException: Cannot forward after response has been
: >committed edu.yale.its.tp.cas.servlet.Login.doGet(Unknown Source)
: >
: >without ever seeing our usual CAS login page, though the URL location is
: >reported by the browser as "https://our.cas.host/cas/login?[...]";
: That looks like an error at the CAS side
: >
: >I don't see anything that stands out in any of the Grouper logs.
: >
: >If I subsequently reload the same UI URL, The UI displays with the URL:
: >
: ><https://our.grouper.host:8443/grouper/populateIndex.do>
: >
: >If I click on the "Log in" link, then the CAS login page that was not
: >initially seen displays as expected. However, after entering username
: >and password credentials, I'm redirected back to a Grouper error page with
: >the URL:
: >
: ><https://our.grouper.host:8443/grouper/callLogin.do?ticket=[...]>
: >
: >and in the grouper_debug.log:
: >
: >2011-10-11 16:59:28,647: [http-0.0.0.0-8443-1] ERROR
: >ErrorFilter.doFilter(142) - < - 0D23BC2ADFFD138F05C2E5514F3019F7-0005 - -
: >- > - javax.servlet.ServletException: org.xml.sax.SAXParseException:
: >Content is not allowed in prolog. yes teststaf
: >12345678
: >Staff K Teststaff
: >staff
: >uhsystem
: >
: > at
: >edu.yale.its.tp.cas.client.filter.CASFilter.getAuthenticatedUser(CASFilte
: >r.java:323) at
: >edu.yale.its.tp.cas.client.filter.CASFilter.doFilter(CASFilter.java:248)
: > at
: >org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicat
: >ionFilterChain.java:235)
: >
: >I recognize the "Content not allowed in prolog" as what our CAS server
: >returns for a successful authentication. i.e.: status of authentication,
: >UH username (uid), UH number (uhuuid, a UH unique identifier), full name,
: >affiliation, etc.
: What version of the CAS server are you using and which 'validate'.
: Looks like you are passing several attributes back - which would not
: be supported by the 'old' casclient.jar supplied
: >
: >I understand that what the Grouper CAS authentication piece wants though
: >is the REMOTE_USER (the uid, in our case). The example provided is based
: >one the GrouperJdbcSourceAdapter2 source adapter, whereas we're using the
: >GrouperJndiSourceAdapter ldap adapter and are using the init-params:
: >
: > <init-param>
: > <param-name>SubjectID_AttributeType</param-name>
: > <param-value>uhuuid</param-value>
: > </init-param>
: > <init-param>
: > <param-name>Name_AttributeType</param-name>
: > <param-value>cn</param-value>
: > </init-param>
: > <init-param>
: > <param-name>Description_AttributeType</param-name>
: > <param-value>cn</param-value>
: > </init-param>
: >
: >I assume at least one/some of my problems is that REMOTE_USER is not being
: >picked up properly by the CAS component and/or is not properly properly
: >configured as one of the subject identifiers. We use uhuuid as our
: >SubjectID because it is the stable unique identifier, whereas the uid is
: >what is I believe being returned as the REMOTE_USER. We are able to
: >successfully use CAS/REMOTE_USER authentication with our Shibboleth IdP
: >deployment, so I'm not focusing my attention there for now.
:
: What is your searchSubjectByIdentifier definition? I think this
: gives you the flexibility to set an arbitrary filter to map the
: REMOTE_USER to the appropriate LDAP attribute.

<search>
<searchType>searchSubjectByIdentifier</searchType>
<param>
<param-name>filter</param-name>
<param-value>
(&amp; (uid=%TERM%) (objectclass=uhEduPerson))
</param-value>
</param>
<param>
<param-name>scope</param-name>
<param-value>
SUBTREE_SCOPE
</param-value>
</param>
<param>
<param-name>base</param-name>
<param-value>
ou=people,dc=hawaii,dc=edu
</param-value>
</param>
</search>

If I understand this correctly, then as long as %TERM% is being set to the
REMOTE_USER, it should be searching the right thing in LDAP. It appears
to work as expected in another deployment where I'm still using a
tomcat-users.xml conf file to define the grouper users and their
credentials.

Aloha,
-baron
--
Baron Fujimoto
<>
:: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum



Archive powered by MHonArc 2.6.16.

Top of Page