Single Sign-On for the UQ Web

Transcription

1 Single Sign-On for the UQ Web David Gwynne Infrastructure Architect, ITIG, EAIT

2 Taxonomy Authentication - Verification that someone is who they claim to be - ie, only the relevant user should know their password, so if they do it verifies their claim to be that user. Authorisation - Permission for the relevant user to access or use a resource

3 Taxonomy Same Sign-On - uniform credentials across all services Single Sign-On (SSO) - enter credentials once for many/all services Single Log-Off (SLO) - log off anywhere makes you log off everywhere

4 Same Sign-On Primarily implemented via login forms or web server modules against AD/LDAP/Kerberos No shared state/session between applications after login Same Sign-On cannot do SLO (see above) UQ has a lot of this (and sometimes not enough) try my.uq, then myaurion, then EAIT

5 Single Sign-On User login becomes a service that applications plug into rather than implement themselves The login service itself maintains a record of a users login, so another application wanting authentication can reuse it

6 Single Sign-On at UQ It does exist! CIS in ITS provide a SAML Identity Provider as part of the suite of UQ authentication backends next to LDAP and Kerberos Provides authentication of users for applications accessed from a web browser

7 SAML Security Assertion Markup Language It is an open standard (close to Shibboleth) Deals with Identity Providers (IdP), Service Providers (SPs), and Principals (users/clients) IdPs need to be configured to trust SPs Provides SLO as part of the protocol too There are several implementations

8 SAML at UQ Central IdP uses simplesamlphp (SSP) Only provides authentication plus real name and an address no authorisation info (ie, no groups) which authz details are useful is arbitrary, so it is better handled by the service payloads need to be small anyway

9 SAML at UQ Separate production and test IdPs you need to ask CIS to add config for either IdP Single Log-Off is not provided by default on logout the IdP sends the client to each SP to destroy those sessions in series if one SP fails to handle logout, the client can t proceed and the whole logout fails

10 Using SAML you ll need a URL for the SP to live at client is sent there to get/set SAML payloads to exchange with the IdP on the apps behalf http is a Bad Idea, https is free at UQ so use it generate certificates you exchange with the IdP used to encrypt and sign payloads between the SP and IdP, not for client to server https

11 Using SAML at UQ Get yourself a trust with the test IdP... you need your SP to be HA before you get SLO EAIT wrote Riak modules for SSP less SPs are better ideally only one SP per OU an SP can act as an IdP though, so you can chain/proxy if needed

12 Using SSP 'default-sp' => array('saml:sp', 'idp' => ' metadata.php', 'privatekey' => 'server.pem', 'certificate' => 'server.crt', 'authproc' => array( 50 => array( 'class' => 'core:attributemap', 'oid2name' ) ) )

13 Using SSP You can provide modules that get run in the authproc phase to manipulate the payload eg, add attributes from a local store SSP comes with modules for querying LDAP and stuff EAIT wrote modules to populate group information from UQ, EAIT, and LABS ADs

14 Using SAML in an app <?php require_once('simplesamlphp/lib/_autoload.php'); $as = new SimpleSAML_Auth_Simple('default-sp'); $as->requireauth(); $attributes = $as->getattributes(); print_r($attributes);?>

15 Using SAML for not PHP Other languages have libraries SSP can fake Basic auth in Apache look for Auth MemCookie in the docs SSP could act as a REST/API endpoint that other things can pass the cookie to Apache subrequests, Apache mod_perl handlers, nginx mod_lua, etc, etc

16 ITS using SAML UQ Drupal hosted on the ITS WSA uses a tweaked version of the simplesamlphp module the whole WSA is treated as a single SP simpler and more robust all the Drupal sites share the one SP Drupal checks the SP state on every request SP log off makes Drupal log off

17 ITS using SAML QNS (Broadhop after an upgrade) login uses SSP against the UQ IdP for authentication Sign-on once for web and internet Blackboard (mostly) works using the UQ IdP as a Shibboleth provider mobile breaks with multiple auth backends but ITS will resolve the issue and make it live

18 EAIT using SAML EAIT has been doing SSO since 2009/2010 Central SAML was only brought up in 2012 We wrote our own SSO/SLO originally apache+php+postgres+mod_perl locking is hard, so we replaced the pg bit kvd (key-value daemon)

19 kvd ~2000 lines of C we wrote ourselves in memory storage (red-black tree) journals to disk so you can restart journals to peers for failover uses UDP as a transport avoids TCP handshake (latency) requests generally take < s

20 kvd We ve written language bindings for PHP, Perl, Python, Ruby, Erlang, etc modules for Apache 1+2 (via mod_perl), nginx (via Lua/Perl), Drupal, Wordpress, Mediawiki, etc our own templating/cms with APIs against it lots of things

21 kvd + SAML We didn t want to replace kvd so we replaced the login/logout forms with SSP EAIT Auth is an application in the SSP model we wrote some modules for SSP Riak storage so we can get SLO AD modules for group memberships

22 Future Work Make Kerberos auth imply SSP login but Kerberos is very brittle Only for specific and tightly controlled environments (labs) Investigate two factor auth Auth with username/password at UQ IdP Auth again with a token at a specific SP

23 Future Work Get other services/ous on board Investigate always on authentication Discuss on the ITLO forum