Date: Thu, 28 Mar 2024 19:19:53 +0000 (UTC) Message-ID: <1956454122.6849.1711653593505@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_6848_415661164.1711653593504" ------=_Part_6848_415661164.1711653593504 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
At Newcastle University we currently protect access to the Grouper User = Interfaces with Shibboleth. Any users trying to access the UI will need to = create a valid session with Shibboleth, before being granted or denied acce= ss to the Grouper application.
The following page will explain how we have achieved this, there maybe s= ome difference in configurations required depending on server set up.
<Loc= ation /grouper> Authtype shibboleth ShibRequireSession On require valid-user </Location>
<Con= nector port=3D"8009" protocol=3D"AJP/1.3" tomcatAuthentication=3D"false" re= directPort=3D"8443" />
ProxyPa= ss /grouper ajp://localhost:8009/grouper
On the install of Grouper 1.5 and the new Lite UI, we encountered proble= ms when accessing the lite UI, when browsing to https://<server-name>= /grouper/grouperUi/appHtml/grouper.html?operation=3DSimpleMembershipUpdate.= index, we encountered an HTTP 403 error. This subsequently highlighted prob= lems when trying to access the admin UI using the link from the grouper hol= ding page, https://<server-name>/grouper/callLogin.do, which also gav= e us a HTTP 403 error.
With the help of the Grouper user mailing list, solutions to solve these= problems were pointed out which we have implemented in our install success= fully.
The main way to overcome the authentication problems was to make use of = the CAS contribution, more details of which can be found on the Yale CAS auth pa= ge.
Gary pointed out the key areas from the CAS contribution that would solv= e the problems we were having with the 403 errors, these changes are docume= nted below;
NOTE: By adding in the CAS contribution to the build of the UI solved th= e problems, below highlights the configurations that are specific to what w= e were wanting to achieve.
When accessing the admin UI through https://<server-name>/grouper/= callLogin.do, this will call the default authentication method for Grouper,= when protected by Shib it needs to bypass this page and go straight to the= Grouper home page. This can be done by amending the action path for callLo= gin in the struts-config.xml, amend this so that it forwards the request to= home.do rather than login.do;
<act= ion path=3D"/callLogin" scope=3D"request" type=3D"edu.internet2.middleware.grouper.ui.actions.CallLoginAction" unknown=3D"false" validate=3D"false"> <forward name=3D"callLogin" path=3D"/home.do" redirect=3D"true"/> </action>
Once this change has been put in plac= e, when the callLogin action is called it will forward the user straight th= rough to the home page as they have already identified themselves through S= hib.
To tell the grouper webapp not to authenticate (leave it to the web serv= er), take out this section (all security stuff):
<sec= urity-constraint> <web-resource-collection> <web-resource-name>UI</web-resource= -name> <url-pattern>/grouperUi/app/*</url-= pattern> </web-resource-collection> <auth-constraint> <role-name>*</role-name> </auth-constraint> </security-constraint> <!--Inserting tag from base file. Merge file was file:/C:/mchyzer/groupe= r/trunk/grouper-ui/temp/99.web.core-filters.xml--> <security-constraint> <web-resource-collection> <web-resource-name>UI</web-resource= -name> <url-pattern>/grouperUi/appHtml/*</= url-pattern> </web-resource-collection> <auth-constraint> <role-name>*</role-name> </auth-constraint> </security-constraint> <!--Inserting tag from base file. Merge file was file:/C:/mchyzer/groupe= r/trunk/grouper-ui/temp/99.web.core-filters.xml--> <security-constraint> <web-resource-collection> <web-resource-name>UI</web-resource= -name> <url-pattern>/grouperExternal/app/*<= ;/url-pattern> </web-resource-collection> <auth-constraint> <role-name>*</role-name> </auth-constraint> </security-constraint> <!--Inserting tag from base file. Merge file was file:/C:/mchyzer/groupe= r/trunk/grouper-ui/temp/99.web.core-filters.xml--> <security-constraint> <web-resource-collection> <web-resource-name>UI</web-resource= -name> <url-pattern>/grouperExternal/appHtml/= *</url-pattern> </web-resource-collection> <auth-constraint> <role-name>*</role-name> </auth-constraint> </security-constraint> <!--Inserting tag from base file. Merge file was file:/C:/mchyzer/groupe= r/trunk/grouper-ui/temp/99.web.core-filters.xml--> <security-constraint> <web-resource-collection> <web-resource-name>Tomcat login</we= b-resource-name> <url-pattern>/login.do</url-pattern= > </web-resource-collection> <auth-constraint> <!-- NOTE: This role is not p= resent in the default users file --> <role-name>*</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>BASIC</auth-method> <realm-name>Grouper Application</realm-name> </login-config> <!--Processing security-role--> <!--Inserting tag from base file. Merge file was file:/C:/mchyzer/groupe= r/trunk/grouper-ui/temp/99.web.core-filters.xml--> <security-role> <description> The role that is required to log in to the G= rouper UI </description> <role-name>*</role-name> </security-role>
This change will now allow users to access through to the lite Ui throug= h the login link or the admin ui when the user has a valid Shib Session, if= they do not have a session they are directed to the Shib login page.
The configurations shown above maybe slightly different for other enviro= nments, though hopefully it will be of some help.
For an overview of authenticating to Grouper using Shib, see also the Grouper UI Training Video, around minute 7.30.= p>