Bug 831937 - [RFE] Support web server provided authentication for REST API
Summary: [RFE] Support web server provided authentication for REST API
Alias: None
Product: Pulp
Classification: Retired
Component: user-experience
Version: 2.0.6
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: Sprint 40
Assignee: Sayli Karmarkar
QA Contact: Preethi Thomas
Depends On:
TreeView+ depends on / blocked
Reported: 2012-06-14 06:31 UTC by Nick Coghlan
Modified: 2015-03-23 01:11 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-01-09 17:07:28 UTC

Attachments (Terms of Use)
Patch to allow web server level preauthentication (5.00 KB, patch)
2012-07-02 05:41 UTC, Nick Coghlan
no flags Details | Diff

Description Nick Coghlan 2012-06-14 06:31:58 UTC
Currently, the REST API expects to handle both user authentication and authorisation checks at the application level.

It would be convenient to be able to tell Pulp to trust the request.vars.REMOTE_USER attribute for REST API access, making it possible to handle authentication at the web server level (e.g. by setting up mod_auth_kerb in Apache).

(Note: for my purposes, letting the web service handle authentication checks would actually be a superior alternative to implementing direct support for authentication against LDAP groups as described in BZ#828072)

Comment 1 Nick Coghlan 2012-06-21 00:57:31 UTC
I've done some initial investigation into patching the version I'm currently using (since rebasing to a more recent version isn't an option right now), and it *looks* like the changes needed would be localised to:


And, of course, a customised version of /etc/httpd/conf.d/pulp.conf that disables WSGIPassAuthorization and configures mod_auth_kerb (and probably mod_authnz_ldap) appropriately instead.

(these are the old paths - adjust appropriately for the new tree layout)

I'm currently thinking an API like the following would make sense:

Add the following function to pulp.server.webservices.http:

    def preauthenticated_username():
        """Checks for a user that has been preauthenticated by the web server"""
        auth = request_info('HTTP_REMOTE_USER')
        if auth is not None:
            # Strip any Kerberos realm information
            # This won't be needed if KrbLocalUserMapping can handle it
            auth, __, __ = auth.partition("@")
        return auth

Modify pulp.server.webservices.controllers.decorators.auth_required to include an additional step before failing:

    # check_preauthenticated is a new authentication checker
    if user is None:
        username = http.preauthenticated_username()
        if username is not None:
            user = check_preauthenticated(username)

pulp.server.auth.authentication.check_preauthenticated would work as follows:

- new optional [preauthenticated] section in pulp.conf
- default-role setting in this section determines role assigned to previously unknown pre-authenticated users (as with the [ldap] section)

Comment 2 Nick Coghlan 2012-06-21 01:01:20 UTC
The behaviour of pulp.server.auth.authentication.check_preauthenticated would be:
- if there is no "[preauthenticated]" section defined, fail immediately
- if the user already exists locally, return their entry
- if the user does not exist, and "default-role" is not set, fail
- otherwise create them with the specified default role

Comment 3 Nick Coghlan 2012-07-02 05:41:25 UTC
Created attachment 595626 [details]
Patch to allow web server level preauthentication

Attached patch adds preauthentication support by always checking for REMOTE_USER before checking HTTP_AUTHORIZATION (or the SSL client cert).

To create the user correctly, the existing "password=None" idiom is extended down into the LDAP lookup mechanism - if the user is preauthenticated, and exists in LDAP, then they will be added automatically with the default role configured in the LDAP settings.

If LDAP is not configured, then the user will be accepted only if they already exist in the database.

The patch is against the old tree layout - hopefully git will be able to follow the file moves and add the extra "platform/" directory in the appropriate places when importing the patch.

Comment 4 Nick Coghlan 2012-07-03 07:51:05 UTC
As an example of how this can be used in practice, a separate WSGIScriptAlias can be defined that refers to the Pulp API web service, but is configured for Apache level authentication checks:

WSGIScriptAlias /pulp/krb /srv/pulp/webservices.wsgi

<Location /pulp/krb>
    AuthName "Pulp API: Kerberos Login"
    AuthType Kerberos
    KrbMethodNegotiate on
    Require valid-user
    KrbAuthRealm EXAMPLE.COM
    KrbVerifyKDC off
    KrbMethodK5Passwd on
    Krb5Keytab /etc/httpd/conf/httpd.keytab
    KrbSaveCredentials on  
    KrbLocalUserMapping On

If a custom client is set up to connect to /pulp/krb instead of /pulp/api, then it can access all the usual Pulp REST API services, while using Kerberos (or any other Apache level authentication mechanism) for authentication checks.

Comment 5 Nick Coghlan 2012-07-13 00:21:02 UTC
Also of potential interest is the custom client I use to connect via Kerberos: http://git.fedorahosted.org/git/?p=pulpdist.git;a=blob;f=src/pulpdist/core/pulpapi.py;h=07dd04f40f474c6e8ab0fc99d8b0211020ab316f;hb=HEAD#l292

(there is also one in that file for connecting via OAuth)

Comment 6 Sayli Karmarkar 2012-10-05 22:36:27 UTC
Submitted pull request as part of authentication refactor and improvement.

Comment 7 Sayli Karmarkar 2012-10-05 22:38:19 UTC
commit ede2c0ce311282729a0fd0a9bbac908b6477975c
Merge: 020e58a 60ee634
Author: skarmark <skarmark>
Date:   Fri Oct 5 15:30:48 2012 -0700

    Merge pull request #99 from pulp/sayli-authentication
    831937 - Added support for webs server level authentication and major refactoring of authentication and auth decorator area.

Comment 8 Jeff Ortel 2012-10-17 16:21:01 UTC
build: 0.332

Comment 9 Preethi Thomas 2013-01-09 17:07:28 UTC
Pulp v2.0 released

Note You need to log in before you can comment on or make changes to this bug.