CAS Server documentation?

[Philip Cummins]

Hello,

I've just been experimenting with the SimpleSAML CAS Server module located here: https://github.com/simplesamlphp/simplesamlphp-module-casserver however found that the documentation has moved or become outdated - is there a guide for how best to configure and set this up?

Thanks,

Philip

[Bjorn Rohde Jensen]

Hi Philip,

I guess, i really should add some documentation of the module on the
projects github wiki. I'll get started on that this weekend..

Anyway, it should be fairly easy to install the module using Composer,
but the module configuration might be a bit intimidating with all the
odd options in the example config.

The good news is, that you can leave quite a lot of the defaults.

scopes are an advanced / niche use case, just leave it an empty list.

legal_service_urls is important. Use a list with a url prefix for each
of your webapplications. The CAS server performs a simple string prefix
match, so you will need both a http and a https entry, if your web
application is accessible using both.

legal_target_service_urls is used for a pretty oscure use case, where
authorization is delegated from one webapp to another and so forth. I
have never heard of anyone actually doing something like this. Just use
an empty array.

ticketstore has wide implications, but there is in my view only one good
choice; memcache. Just comment out or remove the other choices in the
sample config and choose a possibly blank prefix. The prefix is only
really useful for avoiding ticket collisions, if a common store is used
by many CAS servers / modules.

The attribute options really depend on which attributes, you have access
to. attrname should be a unique but not sensitive user id, as it is used
as the users id, and all authorized CAS clients have access to it. CAS
attributes are only available in the CAS 2.0 protocol, and it is up to
you to decide which if any should be available to clients.

The base64 stuff is mostly for preventing xml parsers from choking on
bad attribute values. A popular affliction is latin1 characters in UTF-8
strings. You ought to be able to turn base64 encoding off.

enable_logout should be set to false, since single logout basically
doesnt work in practice. A lot of webapplications keep track of the
users state internally instead of relying on the CAS server. It is also
not obvious to users, what actually happens, when they 'log out'.

skip_logout_page is a proprietary option, which makes it possible to
redirect users to an url specified during log out instead of dropping
them on the CAS servers 'You have been logged out' page.

The various ticket expire times should be fine as is.


Are you familiar with the CAS protocol as such?

Yours sincerely,

Bjorn

[Philip Cummins]

Hello,

I guess, i really should add some documentation of the module on the projects github wiki. I'll get started on that this weekend..

Great, thanks - looking forward to checking it out.

Are you familiar with the CAS protocol as such?

Unfortunately not - I was able to successfully install the cas server module however running into some errors (probably due to my configuration) which if it's OK I can post up tomorrow?

Thanks,

Philip

[Patrick Radtke]

Unfortunately not - I was able to successfully install the cas server module however running into some errors (probably due to my configuration) which if it's OK I can post up tomorrow?

Yes, please post your config and any error messages you get.

I test my CAS config by adding localhost as a legal service url and increasing the service ticket expire time (so I have time to copy and paste curl command)

// module_casserver.php

$config = [

'legal_service_urls' => ['http://localhost'],
'service_ticket_expire_time' => 60,
//Other config options
]

and then doing a request in my browser.

https://myCASIdP.proxy.cirrusidentity.com/module.php/casserver/login.php?service=http://localhost

(note some cas clients assume the path is /cas/login and we use Apache rewrite rules to handle those)

I will then login and get redirect back to

http://localhost/?ticket=ST-3e3fbb28f1aa758f630f95794d26b25b2281fcb04c

I then use the ticket value and curl to call serviceValidate

curl 'https://myCASIdP.cirrusidentity.com/module.php/casserver/serviceValidate.php?service=http://localhost&ticket=ST-9a8f2e9475f31f326dda34cf705dca67446ac75129'

<?xml version="1.0"?>

<cas:serviceResponse xmlns:cas="http://www.yale.edu/tp/cas">

<cas:authenticationSuccess>

<cas:user>user...@cirrusidentity.com</cas:user>

</cas:authenticationSuccess>

</cas:serviceResponse>

Doing such a test will help you know if the issue is in how you configured casserver module or if the issues is on the CAS client side.

[Philip Cummins]

Hello,

OK config wise on my CAS client I'm using the mod_auth_cas module to try and quickly test a secure folder out, config is (just obfuscating our URL with ???):

LoadModule auth_cas_module /usr/lib64/httpd/modules/mod_auth_cas.so

CASCookiePath /var/cache/httpd/mod_auth_cas/

CASLoginURL 'https://simplesaml.anz.???.co/simplesaml/module.php/casserver/login.php'

CASValidateURL 'https://simplesaml.anz.???.co/simplesaml/module.php/casserver/serviceValidate.php'

<Location /arp>

        Authtype CAS

        require valid-user

</Location>

On the SimpleSAML server for module_casserver.conf it is:

$config = array(

    'authsource' => 'test-sql',

    'scopes' => array(),

    'legal_service_urls' => array(

        'https://ufastqlik.anz.???.co/arp',

    ),

    'legal_target_service_urls' => array(),

    'ticketstore' => array(

        'class' => 'casserver:FileSystemTicketStore',

        'directory' => 'ticketcache',

    ),

    'attrname' => 'uid',

    'attributes' => true,

    'attributes_to_transfer' => array('uid', 'displayName', 'roles'),

    'base64attributes' => false,

    'base64_attributes_indicator_attribute' => '',

    'enable_logout' => false,

    'skip_logout_page' => false,

    'service_ticket_expire_time' => 60,

    'proxy_granting_ticket_expire_time' => 3600,

    'proxy_ticket_expire_time' => 60,

);

So at this point I'm able to navigate to https://ufastqlik.anz.???.co/arp and it redirects to SimpleSAML to log in. This works successfully now that I've fixed some MySQL issues however when returning back it uses an URL like https://ufastqlik.anz.???.co/arp?ticket=ST-6e9bdc599c2310579e370bf22283e7d57caa2de2cd which gives "Unauthorized - This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required."

Using your suggestion of curl with longer timeouts it looks like the CAS ticket is OK on the server:

curl -k 'https://simplesaml.anz.???.co/simplesaml/module.php/casserver/serviceValidate.php?service=https://ufastqlik.anz.???.co/arp&ticket=ST-6e9bdc599c2310579e370bf22283e7d57caa2de2cb'

<?xml version="1.0"?>

<cas:serviceResponse xmlns:cas="http://www.yale.edu/tp/cas">

<cas:authenticationSuccess>

<cas:user>pm@edu</cas:user>

<cas:attributes>

<cas:uid>pm@edu</cas:uid>

<cas:displayName>pm</cas:displayName>

<cas:roles>

</cas:roles>

<cas:>false</cas:>

</cas:attributes>

</cas:authenticationSuccess>

</cas:serviceResponse>P

---

Log wise paraphrasing:

UFASTQlik: "GET /arp/ HTTP/1.1" 302 317"

SimpleSAML: "GET /simplesaml/module.php/casserver/login.php?service=https%3a%2f%2fufastqlik.anz.uniforum.co%2farp%2f HTTP/1.1" 302 711"

Log: DEBUG [8d9826c2d6] Session: Valid session found with 'ufast-sql'.

UFASTQlik: "GET /arp?ticket=ST-6e9bdc599c2310579e370bf22283e7d57caa2de2cb HTTP/1.1" 401 381"

So looks like it's able to return ticket info and authenticate, however my CAS client never validates the ticket properly.

Thanks,

Philip

[Philip Cummins]

Hello,

OK looks like the curl out of the mod_auth_cas module is failing due to some SSL certificate issues (we use some intermediate SSL certificate CA's that always seem to have issues for some reason). Good thing is the CAS server appears to be working properly now.

Thanks,

Philip