Keystone Federation via mod_lookup_identity redux

Last year I wrote a proof-of-concept for Federation via mod_lookup_identity. Some of the details have changed since then, and I wanted to do a formal one based on the code that will ship for Kilo. This was based on a devstack deployment.

UPDATE: Looks like I fooled myself: this only maps the first group. There is a patch outstanding that allows for lists of groups, and that is required to really make this work right.


The Configuration of SSSD and mod_lookup_identity stayed the same.
although the sssd-dbus RPM is already installed in F21.

Here is my devstack /opt/stack/devstack/local.conf


[[local|localrc]]
ADMIN_PASSWORD=
DATABASE_PASSWORD=$ADMIN_PASSWORD
RABBIT_PASSWORD=$ADMIN_PASSWORD
SERVICE_PASSWORD=$ADMIN_PASSWORD
SERVICE_TOKEN=password
USE_SSL=True

ENABLED_SERVICES="$ENABLED_SERVICES,-tempest,-h-api,-h-eng,-h-api-cfn,-h-api-cw"

Tempest didn’t like SSL. That is a a recurring problem, and something we need to fix by making SSL the default.
I disabled Heat, too. Nothing against Heat, but I needed to speed up the install, and that was the easiest to leave off.

I’m getting a token with a request that looks like this:

#!/usr/bin/bash

OS_AUTH_URL=https://devstack.ayoung530.younglogic.net/keystone/sss


curl -v  \
-k \
-H "Content-Type:application/json" \
--negotiate -u : \
--cacert ca.crt  \
-d  '{ "auth": { "identity": { "methods": ["kerberos"], "kerberos":{"identity_provider":"sssd", "protocol":"sssd_kerberos"}}, "scope": { "unscoped": { } } } }' \
-X POST $OS_AUTH_URL/v3/auth/tokens

This is due to using the following in the keystone.conf:

[auth]
methods = external,password,token,kerberos

kerberos =  keystone.auth.plugins.mapped.Mapped

This implies that we will want to be able to put Federation data into the kerberos auth plugin for the client.

The trickiest part was getting the mapping right.    I’ve added the mapping to the bottom of this email.

To set up the call, I used the openstack client. After sourcing openrc:

export OS_AUTH_URL=https://192.168.122.182:5000/v3
export OS_USERNAME=admin

openstack --os-identity-api-version=3 group create admins
openstack --os-identity-api-version=3 group create ipausers
openstack --os-identity-api-version=3    identity provider create sssd
openstack --os-identity-api-version=3   mapping create  --rules /home/ayoung/kerberos_mapping_edited.json  kerberos_mapping
openstack --os-identity-api-version=3 federation protocol create --identity-provider sssd --mapping kerberos_mapping sssd_kerberos
       [
            {
                "local": [
                    {
                        "user": {
                            "name": "{0}",
                            "id": "{0}"
                        }
                    }
                ],
                "remote": [
                    {
                        "type": "REMOTE_USER"
                    }
                ]
            },

            {
                "local": [
                    {
                        "group": {
                            "name": "{0}",
                            "domain": {"name": "Default"}
                        }
                    }
                ],
                "remote": [
                    {
                        "type": "REMOTE_USER_GROUPS"
                    }
                ]
            }

        ]

My config for HTTPD Keystone looks like this:

LoadModule lookup_identity_module modules/mod_lookup_identity.so

WSGIDaemonProcess keystone-sss processes=5 threads=1 user=ayoung display-name=%{GROUP}
WSGIProcessGroup keystone-sss
WSGIScriptAlias /keystone/sss  /var/www/keystone/admin


WSGIApplicationGroup %{GLOBAL}
WSGIPassAuthorization On
ErrorLogFormat "%{cu}t %M"
ErrorLog /var/log/httpd/keystone.log
CustomLog /var/log/httpd/keystone_access.log combined
SSLEngine On
SSLCertificateFile /opt/stack/data/CA/int-ca/devstack-cert.crt
SSLCertificateKeyFile /opt/stack/data/CA/int-ca/private/devstack-cert.key


<location /keystone/sss>
  AuthType Kerberos
  AuthName "Kerberos Login"
  KrbMethodNegotiate on
  KrbMethodK5Passwd off
  KrbServiceName HTTP
  KrbAuthRealms AYOUNG530.YOUNGLOGIC.NET
  Krb5KeyTab /etc/httpd/conf/openstack.keytab
  KrbSaveCredentials on
  KrbLocalUserMapping on
  Require valid-user
  SSLRequireSSL
  LookupUserAttr mail REMOTE_USER_EMAIL " "
  LookupUserGroups REMOTE_USER_GROUPS ";"
</location>

I had to pre-create all groups from the mapping due to https://bugs.launchpad.net/keystone/+bug/1429334

1 thought on “Keystone Federation via mod_lookup_identity redux

  1. Good stuff!

    I got this working via mod_authnz_external, which requires pwauth (via PAM). Here’s what I did.

    1. create identity provider ‘sssd’
    2. create mapping similar to the one above, except I changed ‘group’ to ‘groups’ to support multiple groups. i.e.

    “local”: [
    {
    “groups”: {0},
    “domain”: {“name”: “Default”}
    }
    ],
    “remote”: [
    {
    “type”: “REMOTE_USER_GROUPS”
    }
    ]

    NOTE: Keystone mapping only understands semicolon separator for the groups so make sure you have the ‘;’ as the separator when configuring LookupUserGroups like this

    LookupUserGroups REMOTE_USER_GROUPS ;

    3. create a federation protocol, ‘sssd_pam’
    4. add ‘sssd_pam’ to the auth methods

    [auth]
    methods = external,password,token,oauth1,sssd_pam
    sssd_pam = keystone.auth.plugins,mapped.Mapped

    5. add the following to /etc/apache2/sites-enabled/keystone.conf

    AddExternalAuth pwauth /usr/sbin/pwauth
    SetExternalAuthMethod pwauth pipe

    AuthType Basic
    AuthName “SSSD PAM”
    AuthBasicProvider external
    AuthExternal pwauth
    require valid-user

    LookupUserAttr mail REMOTE_USER_EMAIL
    LookupUserGroups REMOTE_USER_GROUPS ;

    6. test it with curl

    curl -v -u username:password -XPOST http://localhost:35357/v3/OS-FEDERATION/identity_providers/sssd/protocols/sssd_pam/auth

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.