mod_auth_pubtkt mod_auth_pubtkt is a pragmatic Web Single Sign-On (SSO) solution.
Download

mod_auth_pubtkt Ranking & Summary

mod_auth_pubtkt Tags

Apache module Apache module Web Single Sign-On SSO solution SSO

mod_auth_pubtkt Description

mod_auth_pubtkt is a pragmatic Web Single Sign-On (SSO) solution. mod_auth_pubtkt is a pragmatic Web Single Sign-On (SSO) solution.The Web SSO dilemmaAre you familiar with this situation? You've got a few (dozen, perhaps) web servers on your company's Intranet, and most/all of them run Apache and require HTTP authentication to access content and scripts stored on them. However, each of them has its own (most likely htpasswd-based) user database, meaning that each time a new employee starts working at your company (or an employee leaves), all the htpasswd files on the various web servers need to be changed. Also, the fact that people need to keep logging in all the time only entices them to store passwords in their browser.If so, then chances are that you've already been looking for a (open source) web single sign-on solution. You may have found projects like Shibboleth, Pubcookie or CoSign, but none of them may have met your requirements (if one did and you're happy with it, then it's probably time to stop reading).At the company that I work for, the requirements for a simple web single sign-on system were as follows:· support for Apache web servers· few/no external dependencies make impact of installing SSO on existing web servers as small as possible· can handle simple authorization (each web server can test whether a user may access a resource without having to ask a remote server)· simple installation/configuration· interfaces to various authentication backends (SQL databases, LDAP, RADIUS, ...) should be easy to implement· reasonably secure· free/open sourceMy evaluations of existing open-source projects turned up the following:· Shibboleth-a very bloated web single sign-on behemoth; way too complicated just to provide SSO in a company Intranet· Pubcookie-basically a nice solution (although configuration is a bit on the complicated side)-zero support for authorization; handles only authentication-forces the use of SSL on all servers (even on trusted LANs)· CoSign-the most promising, but still a bit too complicated for my purposes-service web servers need to communicate with login servermod_auth_tkt to the rescue... well, almostmod_auth_tkt is a simple approach to Web SSO using (session) cookie-based tickets that are generated by a central server and passed to each web server participating in the SSO scheme. The format of the tickets is open, and implementation of a login/ticket-generating server is mostly left to the person deploying mod_auth_tkt. The tickets are signed with MD5 and a shared secret known to the login server and all web servers. This is the only point I didn't like about mod_auth_tkt: if just one single web server's configuration file is compromised, it's possible to generate tickets for all other web servers with the same shared secret.The mod_auth_pubtkt solutionmod_auth_pubtkt is an Apache module that authenticates a user based on a cookie with a ticket that has been issued by a central login server and digitally signed using either RSA or DSA. This means that only the trusted login server has the private key required to generate tickets, while web servers only need the corresponding public key to verify them.Whenever mod_auth_pubtkt encounters a request without a valid ticket/cookie, it redirects the user to a pre-configured login URL, passing the originally requested URL as a GET parameter. The login server can then prompt the user for credentials, verify them using any authentication backend it chooses, and upon success, generate a login ticket (signed with its private key), return it in a cookie to the client, and finally redirect the user back to the originally requested URL.Tickets may contain a list of "tokens", and each resource (directory etc.) can be made to require a specific token, thus giving a simple but effective form of authorization (the login server can assign different tokens to different users, e.g. based on group membership).If the cookie is scoped to the entire domain, all web servers with mod_auth_pubtkt in the domain and configured with the same public key will accept the ticket and not require any further authentication from the client until the ticket expires.Note that a rogue server could steal a valid ticket provided by a client (or it could be sniffed by an adversary if using plain HTTP); however, the client IP address can be included in the ticket, making it harder for other people to use.Ticket formatAuthentication tickets to be processed by mod_auth_pubtkt are composed of key/value pairs, with keys and values separated by '=' and individual key/value pairs separated by semicolons (';'). The following keys are defined; mod_auth_pubtkt silently ignores unknown keys:· uid (required; 32 chars max.)-the user ID (username) that the ticket has been issued for-passed to the environment in REMOTE_USER· validuntil (required)-a UNIX timestamp (the number of seconds since 00:00:00 UTC on January 1, 1970) that describes when this ticket will expire· cip (optional; 39 chars max.)-the IP address of the client that this ticket was issued for-if present, mod_auth_pubtkt will only accept the ticket for requests that came from this IP address-this is usually fine for use on Intranets and is in fact recommended, but may have to be omitted in the presence of NAT or load-balancing proxy servers· tokens (optional; 255 chars max.)-a comma-separated list of words (group names etc.)-the presence of a given token can be made mandatory in the per-directory configuration (using the TKTAuthToken directive), effectively giving a simple form of authorization-the contents of this field are available to the environment in REMOTE_USER_TOKENS· udata (optional; 255 chars max.)-user data, for use by scripts; made available to the environment in REMOTE_USER_DATA-not interpreted by mod_auth_pubtkt· sig (required)-a Base64 encoded RSA or DSA signature over the SHA-1 digest of the content of the ticket up to (but not including) the semicolon before 'sig'-RSA: raw result; DSA: DER encoded sequence of two integers see Dss-Sig-Value in RFC 2459-must be the last item in the ticket stringHere's an example of how a real (DSA) ticket looks:uid=mkasper;cip=192.168.200.163;validuntil=1201383542;tokens=foo,bar;udata=mydata;sig=MC0CFDkCxODPml+cEvAuO+o5w7jcvv/UAhUAg/Z2vSIjpRhIDhvu7UXQLuQwSCF=The ticket string is saved URL-encoded in a domain cookie, usually named auth_dsatkt, but this can be changed (using the TKTAuthCookieName directive).How does mod_auth_pubtkt compare to mod_auth_tkt?Aside from the obvious change in the signature algorithm (RSA/DSA instead of keyed MD5), the following major differences exist:· ticket format changed to allow for future extension (and better human readability)· guest login options removed· ticket refresh removed not possible anymore since the web server doesn't have the private key· ticket expiry is determined by the login server, and not by each web server· GET-based cookie passing removed (but may be reintroduced in the future to allow domain cookie-less operation)Requirements:· Apache Requirements: · Apache

mod_auth_pubtkt Related Software