Cosign Client Behaviour

Notes to try and nail down just how to get the behaviour we want out of Cosign when protecting pages and/or just identifying who's connecting, catering for HTTP and HTTPS. Similar to the behaviour we had with kx509. Note that this has a bit of an Informatics lean to it.

The three cases we are trying to cater for on our main web servers are:

  1. A plain HTTPS service, where data sent and received by the server is encrypted while on the wire. No authentication or authorisation is required.
  2. A DICE/iFriend user is optionally identified (authenticated), so as to provide a tailored view of a web page if possible.
  3. Authentication is required, and optionally authorised, to view content.
  4. We want to be able to delegate the choice of case 1, 2 or 3 to containers in the web tree, by specifying a suitable resources in the .htaccess file (this file will be parsed by both the HTTP and HTTPS servers).

To protect the DICE/iFriends users' credentials, 2 and 3 will have to occur over an HTTPS connection. But we don't want all HTTPS connections to force authentication, or we can't satisfy case 1.

First, the Cosign directives that we use - where they can go and what they do, not including the ones provided by the cosign-client include files that we don't need to know about.

* = default

!CosignProtected *On|Off
Context: !VirtualHost, Location, Directory, .htaccess
Description: If On, will try and authenticate the user (possibly by redirecting to your weblogin host)
and set REMOTE_USER variable. However, see !CosignAllowPublicAccess.

!CosignAllowPublicAccess On|*Off
Context: !VirtualHost, Location, Directory
Description: If On and the location is also "CosignProtected on", then if the user
has not already been authenticated to this web service, then they *will not* be
redirected to your weblogin, instead REMOTE_USER will be set to "(none)"

!CosignHttpOnly On|*Off
Context: !VirtualHost, Location, Directory
Also needed/useful, these directives:
!AuthType Cosign
Context: Directory, .htaccess

Require valid-user
Context: Directory, .htaccess

As we can see from the above, the only directives we can delegate to .htaccess files are CosignProtected, AuthType and Require, which should make it simple. But because both the HTTP and HTTPS service reads these files, simple addition of the cosign directives can (in some instances) cause SSL traffic over HTTP.

Examples

These examples tend to relate to a simple test apache 2.2 service I had running as http://doves.inf.ed.ac.uk.

Normal Required Cosign Protection

With the cosign modules loaded and configured (ie cosign-client included) but CosignProtected Off, then things just work as expected, ie plain HTTP and HTTPS, and no auth. ie Requirement 1

Then if I had CosignProtected in an .htaccess file, with the intention of expecting people to be bounced off to weblogin, and then to the HTTP page:

  • on a DICE firefox, spnego, browser, I get: "...has sent an incorrect or unexpected message. Error Code: -12263".
  • Windows firefox 2.0.0.14, works as hoped, bounced off to https weblogin, but then after entering username and passwd, I get the same error message and code -12263. I've got 3 cookies, 1 from doves (cosign-doves.inf...), 2 from weblogin (cosign & exposedFactors)
  • Windows IE 7, again bounced off to weblogin, but then after entering username and password, again an error. This time IE's "IE Cannot Display the webpage".

The server is generating a redirect page to https://weblogin. The error code you get if you got to https://doves:80

Access HTTPS doves, and things work as expected in all browsers: bounced off to weblogin and then back to https version of doves, with REMOTE_USER set appropriately.

But we don't want HTTP connections giving the problems that it does. Try to fix this by adding:

!RewriteEngine On
!RewriteCond %{HTTPS} !on
!RewriteRule .* https://doves.inf.ed.ac.uk%{REQUEST_URI} [R,L]

to the .htaccess, the hope being that the Rewrite will happen before the CosignProtected directive. Unfortunately it doesn't.

One possible solution is to add CosignHttpOnly On to the server config for the HTTP site. Can't do it in the .htaccess as that will get parsed by both the HTTP and HTTPS servers. This, then, seems to solve the problem, but does mean that the cosign cookie is going plain text for at least one communication before the rewrite kicks in. So we now have a solution for requirement 3 (barring the plain HTTP). But this doesn't solve Requirement 2, ie identify if possible, but don't bounce to weblogin if not.

Optional Cosign Authentication

To satisfy Requirement 2, we'll need to look at using CosignAllowPublicAccess directive. The first issue is that can't go in an .htaccess file, so it needs to go in the server config. Which means we can't meet requirement 4, ie the users can't choose to enable or disable public access themselves.

So, as I understand it, an area marked as cosign-protected and allow-public-access, will always allow someone in, but will only set the REMOTE_USER variable if the user has previously visited some part of the site where authentication is mandatory. So perhaps we can make all of the site public access, apart from one "login" page, then people can do the authorisation via Require.

So now we add CosignAllowPublicAccess On to both the HTTP and HTTPS server. Otherwise someone turning on CosignProtected On, but only to obtain a value for REMOTE_USER if possible, would redirect browsers off to weblogin.inf, which is not what we want in this case (requirement 2). Unfortunately, doing so breaks requirement 3, as the users can't turn off public access in their .htaccess. Hopefully, providing the protected "login" page will be an acceptable solution.

So the first problem is that with:

<directory /var/www/html>
 !CosignProtected Off
 !CosignAllowPublicAccess on
</directory>

<directory /var/www/html/login>
 !CosignProtected On
 !CosignAllowPublicAccess off
 !AuthType Cosign
</directory>

It doesn't appear if the CosignAllowPublicAccess Off in the login branch is being honoured. The apache docs say:

<Directory> (group 1 above) is processed in the order shortest directory component to longest. So for example, <Directory /var/web/dir> will be processed before <Directory /var/web/dir/subdir>.

So the "public access off" should stand for the "login" area.

However trying a <location /login> instead of directory does seem to work ...

<directory /var/www/html>
 !CosignProtected Off
 !CosignAllowPublicAccess on
</directory>

<location /login>
 !CosignProtected On
 !CosignAllowPublicAccess off
 !AuthType Cosign
</location>

Though this works, and so should the <directory> version. The apache docs also suggest:

never use <Location> when trying to restrict access to objects in the filesystem

which is just what I'm doing to solve this problem.

If we say this is the current optimum solution, then it seems we can remove CosignHTTPOnly for the HTTP service, as the CosignAllowPublicAccess stops the redirect to weblogin. This is assuming that we force a secure connection to the "/login" link in the HTTP server and only have the cosign resources in the HTTPS server.

Problems

  • A site configured for optional authentication above, doesn't recognise the user if they had previously visited weblogin.inf.ed.ac.uk off their own back. They have to use the service login page, before the optional auth pages recognise them. This is NOT like kx509, where once you'd been to authportal, any kx509 authed page would identify you.

    It would appear that CosignAllowPublicAccess doesn't even attempt to get a service cookie, even though the user has a login cookie.

  • Again a site configured for optional auth, then a user can't create a .htaccess that will force a user off to weblogin to force authentication, ie requirement 3. I suspect this could be solved if the CosignAllowPublicAccess directive was allowed in .htaccess files.

  • With an area given restricted access with the following directives:
    !CosignProtected On
    !AuthType Cosign
    Require user jsmith@foobar.com
    

    Then even if the browser has been authenticated, apache throws a 401 error, when I would have expected a 403 (Forbidden) error code. Though this may be because this area is also !CosignAllowPublicAccess on, I've not had time to see if that makes a difference yet, I don't see why it should though.

  • Using apache 1.3 and cosign, the following (in an .htaccess access file) gives an error "configuration error: couldn't check user. No user file?"
    !CosignProtected On
    !AuthType Cosign
    !AuthGroupFile /liveroot/conf/access/group.capabilities
    Require group auth/login/hase
    

    When that location has CosignAllowPublicAccess on set in the server config. With it set to off, it works as expected. This doesn't seem to affect Apache 2.2

-- NeilBrown - 13 May 2008

Topic revision: r5 - 26 May 2014 - 16:06:56 - RogerBurroughes
 
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies