Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] Grouper UI authentication with CAS

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] Grouper UI authentication with CAS


Chronological Thread 
  • From: Baron Fujimoto <>
  • To: Grouper Users <>
  • Subject: Re: [grouper-users] Grouper UI authentication with CAS
  • Date: Tue, 13 Oct 2015 09:14:49 -1000

Hi, I thought I'd try one last call out to see if any one has any feedback
on this before I forge ahead with other tasks and have to leave this
potential kludge or partial solution in place.

To recap, Is this logout/login login.do/home.do behavior a bug or
misconfiguration on our end? What is are the best practices for this type
of customization: edit struts-config.xml (or similar files) directly in
the unpacked distribution path, or try to factor them out as seems to be
suggested by the documentation? Any guidance would be appreciated.

Aloha,
-baron

On Tue, Oct 06, 2015 at 05:43:31PM -1000, Baron Fujimoto wrote:
>I recently discovered behavior that isn't present in our previous 2.1.5
>install.
>I've deployed the UI with CAS for authentication as described below and it
>generally seems to work. If I click on the "Log out" link, I'm logged out, as
>expected. However, if I then click on the "Log in" link on the
>/grouper/logout.do
>landing page, it sends me back to CAS for authentication again but also
>prompts
>me for standard HTTP type authentication. When it fails, I get the 401
>status response
>and the error, "This request requires HTTP authentication" for the page
>grouper/login.do.
>
>If I go to any other page, e.g., /grouper, it reuses the existing CAS SSO
>session
>and lets me in without reauthenticating. This is the expected behaviour,
>based on
>our experience with 2.1.5.
>
>In configuring CAS authentication for the UI I had factored out changes for
>the customization[*] rather than grouper-ui/webapp/WEB-INF/struts-config.xml
>as follows,
>
>[*] as described here
><https://spaces.internet2.edu/display/Grouper/Customising+the+Grouper+UI#CustomisingtheGrouperUI-web.xml>
>
>=====
>grouper/grouper-ui-custom/webapp/WEB-INF/struts-config-custom.xml:
><?xml version="1.0" encoding="ISO-8859-1"?>
>
><!DOCTYPE struts-config PUBLIC
> "-//Apache Software Foundation//DTD Struts Configuration 1.1//EN"
> "http://jakarta.apache.org/struts/dtds/struts-config_1_1.dtd";>
>
><struts-config>
>
> <action path="/callLogin" scope="request"
>
> type="edu.internet2.middleware.grouper.ui.actions.CallLoginAction"
> unknown="false" validate="false">
>
> <forward name="callLogin" path="/home.do" redirect="true"/>
> </action>
>
></struts-config>
>=====
>
>If I edit grouper-ui/webapp/WEB-INF/struts-config.xml directly instead of
>struts-config-custom.xml to replace login.do with home.do for /callLogin,
>
>I get a different error, "You have an anonymous session since you are not
>logged in, but this section requires you to be logged in. Maybe No
>username found. Your identity provider might not be sending your username
>to this application. Either you need to use a different identity provider,
>or ask your IT department to send your username to this application." I'm
>invited to "Start over", and if I click on that link, I'm dropped back to
>/grouper/grouperUi/app/UiV2Main.index in a logged in state. This seems
>more akin to the behavior we saw in 2.1.5 though, and is probably more
>correct.
>
>Is there a way to make this work using the factored out
>struts-config-custom.xml, or should I abandon this approach and just
>modify struts-config.xml directly? For out 2.1.5 deployment, I modified
>struts-config.xml directly. For this 2.2.1 deployment though, I was trying
>to adapt the documentation referenced above. Is this in fact the
>recommended approach?
>
>Aloha,
>-baron
>
>On Tue, Aug 25, 2015 at 05:44:28PM -1000, Baron Fujimoto wrote:
>>Thanks to all for the sugestions and offers of help. I managed to get it
>>working by generally following my original strategy once I worked around
>>the errors I was encountering. I got past them by doing the following:
>>
>>In the grouper-ui build.xml, in the additional-build section, comment out
>>the following:
>><property name="uicp" refid="ui.class.path.for.run"/>
>>Ironically, this follows immediately after the comment:
>><!-- In trying to debug why ui.class.path was not inherited the problem
>>went away when the line below was added for debugging!-->
>>
>>Additionally, in the specified additional-build.xml file, this diff:
>>--- grouper/grouper-ui/additional-build.template.xml
>>+++ grouper/grouper-ui-custom/additional-build.xml
>>@@ -12 +12,1 @@
>>- <property name="cp3" refid="ui.class.path" />
>>+ <property name="cp3" refid="ui.class.path.for.run" />
>>
>>Both of these changes were necessary to build without error.
>>
>>Upon testing the UI, we discovered a previously seen error:
>>org.apache.jasper.JasperException: /WEB-INF/jsp/dynamicTile.jsp (line: 34,
>>column: 6) "${uiException.class.simpleName}" contains invalid
>>expression(s): javax.el.ELException: Failed to parse the expression
>>[${uiException.class.simpleName}]
>>
>>This one is resolved with this diff:
>>--- grouper-ui/webapp/WEB-INF/jsp/dynamicTile.jsp.invalid_expression_err
>>+++ grouper-ui/webapp/WEB-INF/jsp/dynamicTile.jsp
>>@@ -34 +34 @@
>>- <!-- <c:out value="${uiException.class.simpleName}"/>:<c:out
>>escapeXml="false" value="${uiException.message}"/> -->
>>+ <!-- <c:out value="#{uiException.class.simpleName}"/>:<c:out
>>escapeXml="false" value="${uiException.message}"/> -->
>>
>>Should any of these be incorporated into future patches?
>>
>>On a more general note, is there a Best Practice for how to approach these
>>types of customizations? More specifically, the yale-cas-auth README
>>suggests extending the UI via the method described here:
>><https://spaces.internet2.edu/display/Grouper/Customising+the+Grouper+UI#CustomisingtheGrouperUI-modifyingstruts>
>>
>>This seems to have the advantage of making the changes a little more
>>portable across compatible versions of the app by factoring them out to
>>an external directory hierarchy. The "Implementing CAS Authentication for
>>Grouper" wiki page chooses to modify struts-config.xml directly though.
>>Can you also overlay the fixed version dynamicTile.jsp in the
>>grouper-ui-custom/webapp/WEB-INF/jsp/ directory somehow? If not, it seems
>>to lessen the benefit of factoring out these customizations since the
>>still wind up scattered about in different directories.
>>
>>Aloha,
>>-baron
>>
>>On Fri, Aug 21, 2015 at 11:10:05AM -0700, John Gasper wrote:
>>>I¹ve successfully used these instructions:
>>>https://spaces.internet2.edu/display/Grouper/Implementing+CAS+Authenticatio
>>>n+for+Grouper
>>>
>>>--
>>>John Gasper
>>>IAM Consultant
>>>Unicon, Inc.
>>>PGP/GPG Key: 0xbafee3ef
>>>
>>>
>>>
>>>
>>>
>>>
>>>On 8/20/15, 10:21 PM, "Baron Fujimoto"
>>><
>>> on behalf of
>>>>
>>> wrote:
>>>
>>>>I'm attempting to configure the Grouper (2.2) UI to authenticate using
>>>>CAS.
>>>>
>>>>The basic documentation I'm trying to follow is:
>>>><https://spaces.internet2.edu/display/Grouper/Customising+the+Grouper+UI#C
>>>>ustomisingtheGrouperUI-authn>
>>>>
>>>>The "Yale CAS Authentication" link points to
>>>><https://spaces.internet2.edu/display/Grouper/Contributions>
>>>>
>>>>but that page warns that it's an older version and that a the newer
>>>>contributions page should be used instead:
>>>><https://spaces.internet2.edu/display/Grouper/Community+Contributions>
>>>>
>>>>On that page, under Code Contributions, there's a link to "yale-cas-auth"
>>>>that points to
>>>><http://middleware.internet2.edu/dir/groups/grouper/grouper-0.9/ui-docs/co
>>>>ntrib/yale-cas-auth/README.html>
>>>>
>>>>but that page is 404.
>>>>
>>>>However, I'm assuming that README.html is the same one found in
>>>>grouper.ui-2.2.1/contrib/yale-cas-auth/
>>>>
>>>>The README advises to build it using the "additional.build" property.
>>>>
>>>>In build.properties, I have set:
>>>>additional.build=${basedir}/../grouper-ui-custom/additional-build.xml
>>>>
>>>>and in ../grouper-ui-custom/additional-build.xml I have:
>>>>=====
>>>><project name="additional">
>>>>
>>>> <target name="webapp">
>>>>
>>>> <!-- if i dont have this here, it doesnt work (doesnt pass it on to
>>>>other ant file) -->
>>>> <property name="cp3" refid="ui.class.path" />
>>>>
>>>> <ant antfile="build.xml" target="webapp"
>>>>dir="${contrib.dir}/yale-cas-auth" inheritrefs="true" />
>>>>
>>>> </target>
>>>>
>>>> <!-- this target is required even if blank -->
>>>> <target name="resources">
>>>>
>>>> </target>
>>>>
>>>></project>
>>>>=====
>>>>
>>>>However when I try to build with "ant dist" I get the following error:
>>>>=====
>>>>...
>>>>-additional-build:
>>>> [echo] Calling site specific build script -
>>>>'/home/grouper/grouper/grouper.ui-2.2.1/../grouper-ui-custom/additional-bu
>>>>ild.xml' - target=resources
>>>>
>>>>BUILD FAILED
>>>>/home/grouper/grouper/grouper.ui-2.2.1/build.xml:193: The following error
>>>>occurred while executing this line:
>>>>/home/grouper/grouper/grouper.ui-2.2.1/build.xml:773: The following error
>>>>occurred while executing this line:
>>>>/home/grouper/grouper/grouper.ui-2.2.1/build.xml:332: The following error
>>>>occurred while executing this line:
>>>>/home/grouper/grouper/grouper.ui-2.2.1/build.xml:658: Reference
>>>>ui.class.path.for.run not found.
>>>>=====
>>>>
>>>>So I'm stuck here at the moment.
>>>>
>>>>The yale-cas README also instructs you to override the callLogin action
>>>>in struts-config.xml and references another defunct page at
>>>><https://wiki.internet2.edu/confluence/display/GrouperWG/Customising+the+G
>>>>rouper+UI+v1.0>
>>>>
>>>>I'm assuming these are the current docs for how to do this:
>>>><https://spaces.internet2.edu/display/Grouper/Customising+the+Grouper+UI#C
>>>>ustomisingtheGrouperUI-modifyingstruts>
>>>>
>>>>So I have the (as yet untested) in
>>>>grouper-ui-custom/webapp/WEB-INF/struts-config-custom.xml
>>>>=====
>>>><?xml version="1.0" encoding="ISO-8859-1"?>
>>>>
>>>>
>>>><!DOCTYPE struts-config PUBLIC
>>>> "-//Apache Software Foundation//DTD Struts Configuration
>>>>1.1//EN"
>>>> "http://jakarta.apache.org/struts/dtds/struts-config_1_1.dtd";>
>>>>
>>>><struts-config>
>>>>
>>>> <action path="/callLogin" scope="request"
>>>>
>>>>type="edu.internet2.middleware.grouper.ui.actions.CallLoginAction"
>>>> unknown="false" validate="false">
>>>>
>>>> <forward name="callLogin" path="/home.do" redirect="true"/>
>>>> </action>
>>>>
>>>></struts-config>
>>>>=====
>>>>
>>>>Is this the right approach? I didn't see the equivalent of an
>>>>additional.build definition to tell it to actually look for the
>>>>struts-config-custom.xml file, but I'm trying to piece this together from
>>>>the what I find in the wiki so I kind of guessing at the moment.
>
>--
>Baron Fujimoto
><>
> :: UH Information Technology Services
>minutas cantorum, minutas balorum, minutas carboratum desendus pantorum

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



Archive powered by MHonArc 2.6.16.

Top of Page