ADMIRAL SSO credentials

From ImageWeb

Jump to: navigation, search

Contents

Single sign-on authentication notes

(Lightly edited from local file 20100105-AuthenticationNotes.txt)

The question

Roughly this requirement was posed to the Oxford IT Support Staff mailing list:

We plan to create a file system shared at research-group and/or departmental level, around which additional web-based services can be constructed. Without writing any new software.

I'm looking for ways to simplify authentication of research users to a range of Linux-hosted facilities; specifically:

(a) web page access via Apache httpd,
(b) ssh access (including tunnelling),
(c) file access via Samba,
(d) programmatic web service access via Apache httpd (including file access via WebDAV).

I've read a little about Linux PAM, and was wondering if there is a suitable PAM module to support authentication by Oxford SSO username, avoiding the need for researchers to maintain multiple account names and passwords.

I'm pretty sure it's possible to do:

(a) web page access (this is what Shibboleth does, right?)
(b) SSH access (linux.ox.ac.uk achieves this)
(c) I'm guessing that the mechanism used for ssh login could be hooked by Samba - as I recall, Samba can use the normal Linux account authentication mechanisms, which is what I guess is underlying the linux.ox.ac.uk ssh login.
(d) is an area that I know can be problematic for Shibboleth mechanisms, but I'm thinking that if there's a WebAuth PAM module then Apache could use that instead of the Shibboleth-style web page redirection. In the case of WebDAV, I seem to recall that some fancy footwork is required around group membership if Linux account based authentication is being used, but the host system will be dedicated so that is probably acceptable.

Responses

Christian Fernau

Both the webauth as well as shibboleth are purely browser based profiles. They won't work with any other clients. For non-browser based access you could use something like SAML2/Kerberos/SPNEGO/X509/...

(a) web page access via Apache httpd,
You can use webauth (oxford only) or SAML/Shib (ox+world) to do this.
(b) ssh access (including tunnelling),
This should be possible with a kerberos enabled desktop (e.g. using kinit) and there's something on windows which does the same. But using an SSO user/password over SSH (using "normal" tunneled password authn) won't be allowed by OUCS because the users passwords would be exposed your host (but you can ask).
(c) file access via Samba,
Not sure how that would work or what Samba supports.
(d) programmatic web service access via Apache httpd (including file access via WebDAV).
Something like SPNEGO could work. But SPNEGO + Kerberos proxy-tickets + WebDAV isn't going to be a rock solid solution - I can't think of one decent implementation of any of those! This is an interoperability nightmare. X509 might solve this problem for you. There is no huge benefit from using SSO for machine-machine communication. What exactly are you trying to do?

Michael Howe

If all your users have Oxford SSO accounts, I think you probably want to be looking at kerberos (which is what webauth uses for authentication), and there is indeed a PAM module[0] (in Debian/Ubuntu, in the libpam-krb5 package) that will cover point b) for you. I was hoping that I could point you at <https://wiki.oucs.ox.ac.uk/itss/KerberosUnix> and it would explain all - it doesn't quite seem to cover PAM, though. Note that you need to get a source of all the allowed usernames from somewhere, which I suspect will be the harder part - if they're (reasonably) static, you could just add new user accounts manually, otherwise, I don't know if there's some way you could use Oak LDAP - sysdev may be able to help here.

Brief browsing of the wiki before closing the tab brought me to https://wiki.oucs.ox.ac.uk/itss/OULD/KerberosAndAFS which may also be helpful.

For a), I'd suggest that simply webauthing things would be best. Otherwise, you can use the auth_kerb apache module ^1^. The module does various clever auto-negotiation things (so if you already have a kerberos credentials cache, you can be automatically logged in), but those aside it does Basic auth against a kerberos realm. It's _not_ the same as webauth, even though users enter the same username and password (and I don't know whether you can use the same webauth principal, or if you require a HTTP/fqdn@OX.AC.UK principal - although sysdev should be able to help with this).

As for d), I think you want the auth_kerb apache module - I assume most software's happy with Basic authentication.

I've done most of my kerberos testing on a non-Oxford realm, but if any of the above seems useful and you want sample configs, I can probably dig some out.

I'd also add that most of the problems I've had with Kerberos have been due to either a) time not being correct (it needs to be within 5 minutes of OUCS's servers, or things don't work) or b) DNS issues (forward/reverse DNS not matching, hostnames not being properly qualified, etc). I mention this because I've spent more hours than I care to admit wondering why what _should_ be correct is producing obscure error messages.

Links:

  1. https://wiki.oucs.ox.ac.uk/itss/KerberosUnix
  2. https://wiki.oucs.ox.ac.uk/itss/OULD/KerberosAndAFS

Note: we will need to request a Kerberos principal from the sysdev team:

John Pybus

Is the notion of using a WebAuth PAM module reasonable?
I'd say, not really. PAM modules are used to authenticate users in many situations such as an ssh login/the console/the X display manager. WebAuth is a web based Single Sign On system; it interacts with the user by web forms, these can only be presented to the user if the resource is being accessed through a web browser.
WebAuth is actually based on kerberos behind the scenes, in fact it would probably be more accurate to say that WebAuth is a way to pass around kerberos tokens in web browser sessions. Kerberos is based on issuing tickets rather than on username/password so while many other services can use kerberos they tend to need customised clients which can pass/manage thois tickets (there is a kerborised ssh client but that doesn't necessarily mean all other services could use kerberos)
(a) web page access (this is what Shibboleth does, right?)
OK, Shibboleth is another layer removed from WebAuth. shib is a federated system which ends up passing SAML assertions through web sessions. In Oxford's implementation the user authentication is via Oxford's webauth, but in other institutions it would be via other mechanisms; there is no consistency so it's very tied to web browser sessions. The interesting thing with shib are what attributes your identity provider may send to services you use and the trust relationships to allow it (so when you log into Nature's website, Oxford's Id Provider will say that you're a member of staff at Oxford, but not what your name is, and because of the federation agreements Nature will trust this to give you access to the appropriate content). Probably not a good fit to your problem though.
(b) SSH access (linux.ox.ac.uk achieves this)
Looking at the files in /etc on linux.ox.ac.uk (mostly publicly readable) it looks like linux.ox.ac.uk is using LDAP to authenticate users. Presumably to the same credential store as backs the WebAuth service -- I believe that these days OUCS are branding all their services in this area as OAK.
I'd imagine it could also be done via kerberos, but then the user would have to get a kerberos ticket rather than use a normal username/password. This would work with some clients but not all (so your command line ssh might work, but not your nice sftp gui).
(c) I'm guessing that the mechanism used for ssh login could be hooked by Samba - as I recall, Samba can use the normal Linux account authentication mechanisms, which is what I guess is underlying the linux.ox.ac.uk ssh login.
True. But you could also use kerberos here, and samba supports that (they have to since microsoft's Active Directory is based on kerberos).
You could probably set up samba login/access via Oxford SSO, I think some colleges have done so, but I think getting it to work well with MS's clients is tricky. If they're already logged into their local Active Directory domain then it might not be possible.
(d) is an area that I know can be problematic for Shibboleth mechanisms, but I'm thinking that if there's a WebAuth PAM module then Apache could use that instead of the Shibboleth-style web page redirection. In the case of WebDAV, I seem to recall that some fancy footwork is required around group membership if Linux account based authentication is being used, but the host system will be dedicated so that is probably acceptable.
There is probably a tension between the user/password login you need to make HTTP-basic auth work for WebDAV/programatic-web-APIs and OUCS's ideas of password security.
Technically, you can do this with LDAP, but I don't think OUCS's LDAP service exposes enough info to allow you to do PAM style login like linux.ox.ac.uk does. If you were to allow webDAV/http-based-APIs then the password might get used in plain-text over http:// and will certainly get cached by the OS. As far as I know OUCS can only offer authentication via kerberos, or webAuth (which is kerberos in a web interface anyway).
Weblearn (OUCS's own service) uses WebAuth sign-on and it does offer webDAV, but to get around this, if you want to use the webDAV then it creates you a second username and password just for that.

John Ireland

(a) web page access via Apache httpd,
Either the Apache WebAuth module (part of many standard Linux distributions - it's just an Apache authentication module, and can be accompanied by mod_webauthldap which offers authorisation support), or the Apache Shibboleth module will suit here. PAM isn't a common route for solving web-based authn/authz requirements, although it certainly is possible.
(b) ssh access (including tunnelling),
Yes, you can simply configure sshd's PAM setup to use Kerberos against the University Kerberos service. The required Kerberos configuration is already detailed in our Webauth instructions (section 3.1 at http://www.oucs.ox.ac.uk/webauth/index.xml.ID=body.1_div.3). If you need further assistance then do let us know.
Kerberos will handle the authentication (SSO) side of things, but you'll still need a source of account details (LDAP is commonly used to do this).
(c) file access via Samba,
Samba can indeed use PAM, so can use Kerberos as with ssh. Again, you'll need your local source of account info (the LDAP source you setup for ssh can be used again).
(d) programmatic web service access via Apache httpd (including file access via WebDAV).
This scenario isn't particularly suited to Webauth. Typically the requirement is for the program to authenticate in its own right rather than on behalf of a user, so the SSO issue isn't as important, and other methods of authentication such as x509 client certificate are suitable.
Much of this confirms what you already know - if you want more info then do shout.

Links:

Summary

I now realize that, in phrasing my original question, I confused WebAuth with the underlying Kerberos service: it appears that my requirements (b) and (c) can be addressed using Kerberos.

For WebDAV access, I'm prepared to fall back to a non-SSO account if necessary, since this seems likely to be a marginal use-case.

And for other web services, I still need to think more deeply about what it is that I need to achieve. The main requirement I foresee is support for AJAX-type applications, so the necessary tokens will hopefully be established when accessing the containing web page.

The following links all look very helpful:

In due course, I'll document our efforts and provide a pointer.

Retrieved from "http://imageweb.zoo.ox.ac.uk/wiki/index.php/ADMIRAL_SSO_credentials"
Personal tools
Oxford DMP online
MIIDI
Claros