In this exercise you'll make a configuration change to the CAS server included with uPortal that will change it to authenticate where the presented username is the same as the presented password, rather than relying upon the database of users shared between CAS and uPortal in the default configuration.
This will allow you to log in as any user you like (simply entering the asserted username as the password.)
Step 1: Verify that you can't yet log in as scott.
Scott Battaglia is the lead developer of the CAS project, so "scott" seems a good test username.
Verify that before changing anything, you can't log in as scott / scott.
When you try to log in with username and password "scott", you'll get an end-user-facing error message. This is because there's no user "scott" with password "scott" in the default dataset.
Step 1: Edit the deployerConfigContext.xml
Edit deployerConfigContext.xml, setting it to use the default-for-CAS (but not default-for-CAS-as-distributed-with-uPortal) authentication handler.
The file to be edited is at
/up31seminar/uPortal-3.1.0-M2-quick-start/uPortal-3.1.0-M2/uportal-portlets-overlay/cas/src/main/java/webapp/WEB-INF/deployerConfigContext.xml
This property declaration:
<property name="authenticationHandlers">
<list>
<!--
This is the authentication handler that authenticates services by means of callback via SSL, thereby validating |
a server side SSL certificate. |
This is the authentication handler declaration that every CAS deployer will need to change before deploying CAS |
into production. The default SimpleTestUsernamePasswordAuthenticationHandler authenticates UsernamePasswordCredentials |
where the username equals the password. You will need to replace this with an AuthenticationHandler that implements your |
local authentication strategy. You might accomplish this by coding a new such handler and declaring |
edu.someschool.its.cas.MySpecialHandler here, or you might use one of the handlers provided in the adaptors modules. |
Becomes this:
<property name="authenticationHandlers">
<list>
<!--
This is the authentication handler that authenticates services by means of callback via SSL, thereby validating |
a server side SSL certificate. |
<bean
class="org.jasig.cas.authentication.handler.support.SimpleTestUsernamePasswordAuthenticationHandler" />
</list>
</property>
]
The deployerConfigContext.xml file as it ships with uPortal 3.1.0 M2 is included in the "before" folder alongside this file if you're reading this as a PDF distributed in the seminar and is available from Jasig SVN so if you accidentally mangle the file and want the original back, simply replace with a fresh copy.
Likewise, the deployerConfigContext.xml with the described change is included in the "after" folder alongside this file if you're reading this as a PDF in the seminar and is attached here regardless, so if you'd like to proceed straight to the solution rather than bother with pasting bits of XML, feel free to copy that "after" deployerConfigContext.xml file into place.
Step 2: Be sure your portal is stopped
Step 3: Run the Ant deploy-ear to deploy the modified CAS
cd /up31seminar/uPortal-3.1.0-M2-quick-start/uPortal-3.1.0-M2 ../ant.sh deploy-ear
Step 4: Start the portal again
After you wait for uPortal to start up, you can see it in your web browser at
http://localhost:8080/uPortal/
Step 5: Try it out
You should now be able to log in as scott / scott . Or as any other username == password pair. Note that uPortal just in time creates user accounts for these users authenticated by the configured authentication mechanism. There's no requirement to pre-provision uPortal with all the users in your enterprise directory or who may be able to authenticate using your configured authentication mechanisms. (Indeed, pre-provisioning the portal wtih user accounts for all possible users may be impossible if e.g. you configure uPortal to use Shibboleth and participate in federated identity management).