Demystifying Identity FederationColleen Murphy ~ cmurphy ~ @_colleenm

2

About me

● Cloud developer at SUSE● Keystone core reviewer

3

Overview

● What is identity federation?● Vocabulary● Types of federation in keystone● Auth flows● Demo time - let’s set up keystone federation!● Mappings● Future plans

4

What is federated identity?

Federated Identity is the ability to share a single authentication mechanism across many systems, in our case clouds.

Typically, your organization will already have a source of identity, so creating another set of credentials just for your cloud is annoying. Your cloud should understand how to talk to your identity provider.

5

What is identity federation?

OR - you have partner organizations with shared resources. You want to give individuals from your partner organization access to your resources without creating internal accounts for them. You could then set up your cloud to trust their identity provider.

6

What is identity federation?

OR - you have a “bursty” workload that needs to occasionally work on public clouds (or a hosted private cloud). You use your local keystone as an identity provider, and the public/hosted private cloud acts as the service provider.

7

Why is it better than an LDAP backend?

A federated identity provider abstracts the actual identity storage behind an authentication protocol, so you don’t have to give your password directly to keystone, your authentication is done directly with the provider.

8

How does this work in keystone?Two types of federation in keystone:● Keystone using an external identity provider as an auth method

(introduced in Icehouse)○ Handled almost entirely by an HTTPD module sitting in front

of keystone● Keystone as an identity provider (Keystone to Keystone)

(introduced in Kilo)

9

Vocabulary

Service Provider (SP)● The thing with the resource you need.● In our case this is keystone, which provides keystone tokens that

we use for other OpenStack services.Identity Provider (IdP)● The thing that accepts your credentials, validates them, and

generates a yay/nay response and some attributes about you.

10

Vocabulary

Entity ID, Remote ID● A unique identifier for either an SP or an IdP.● Usually takes the form of a URI, but it is not required to resolve to

anything.● Only requirement is that it is unique within an IdP/SP system● Example: https://idp.testshib.org/idp/shibboleth

SAML2.0● A common federation authentication protocol

Assertion● A formatted statement from the identity provider that asserts that

a user is authenticated and provides some attributes about them

11

FAQ

● What are shadow users?○ A local copy of the user attributes that keystone needs to

function, like a username, as well as an internally generated ID so that keystone can assign roles to the user

12

FAQ

● What federated protocols are supported?○ Keystone as a service provider: any protocol that can convert

user attributes to environment variables in an HTTP request■ SAML2.0, OpenID Connect, x509, Kerberos

○ Keystone as an identity provider: only SAML2.0

13

FAQ

● Does this work when keystone sits behind a proxy?○ Yes, but you need to pay attention to where requests are

being sent and ensure the auth protectors and the SAML handlers match

14

FAQ

● Can I have LDAP and federation at the same time?○ Yes! LDAP is an identity backend, and federation is an auth

method. They can coexist.

15

FAQ

● What if my identity provider is behind a firewall?○ SAML2.0: no direct connection is needed between the IdP

and the SP, all negotiation is done through the browser/ECP○ OpenID Connect: the SP needs to be able to request a token

from the IdP directly (not usually a problem because the IdP is usually Google)

16

Overview of auth flows● Normal keystone● SAML2.0 WebSSO● SAML2.0 ECP● SAML2.0 WebSSO with horizon● OpenID Connect● x509● Kerberos

● Keystone to Keystone

Find these slides at http://gazlene.net/demystifying-identity-federation.pdf

1717

Normal keystone

1818

SAML2.0 WebSSO

1919

SAML2.0 ECP

2020

WebSSO with keystone and horizon

2121

Keystone to Keystone

22

Before you start

● Set debug=true and insecure_debug=true in keystone● Set the console logging handler to debug in horizon● If possible, turn on debug logging on your IdP● Install the SAML Tracer plugin on Firefox

23

Demo time

24

Keystone with an external IdP

25

Have an identity provider

For this demo I used this node.js app:

https://github.com/mcguinness/saml-idp

26

Setup horizon

● Set WEBSSO = True● Add a protocol to WEBSSO_CHOICES

WEBSSO_CHOICES = ( ("credentials", "Keystone credentials"), ("saml2", "My Awesome IdP"))

27

Create federation resources in keystone

$ openstack identity provider create demoidp --remote-id=urn:example:idp

$ openstack mapping create --rules rules.json demomap

$ openstack federation protocol create saml2 --identity-provider demoidp --mapping demomap

28

Install the mod_shib package (or the equivalent for your distro)

Set up Apache

29

Add protected Locations to your apache vhost

Set up Apache

Proxypass Shibboleth.sso !<Location /Shibboleth.sso> SetHandler shib</Location>

<Location /identity/v3/OS-FEDERATION/identity_providers/demoidp/protocols/saml2/auth> AuthType shibboleth Require valid-user ShibRequestSetting requireSession 1 ShibExportAssertion Off</Location>

<Location /identity/v3/auth/OS-FEDERATION/websso/saml2> AuthType shibboleth Require valid-user ShibRequestSetting requireSession 1 ShibRequireSession On ShibExportAssertion Off</Location>

30

# shib-keygen

Generate keys

31

Edit /etc/shibboleth/shibboleth2.xml

<ApplicationDefaults entityID="http://sp.keystone.demo/shibboleth" REMOTE_USER="eppn persistent-id targeted-id">#...<SSO entityID="urn:example:idp">#...<MetadataProvider type="XML" file="/etc/shibboleth/idp.saml.demo.xml" />

Configure metadata

32

Install the IdP’s metadata at the location you configured:

<MetadataProvider type="XML" file="/etc/shibboleth/idp.saml.demo.xml" />

Exchange metadata

33

Restart shibd and apache:

# systemctl restart shibd apache2

Download metadata:

$ wget \ https://sp.keystone.demo/Shibboleth.sso/Metadata

Configure metadata

34

● Add saml2 as an [auth]/method● Set a [saml2]/remote_id_attribute● Set a [federation]/trusted_dashboard● Create a federated group to match your mapping● Copy the SSO template into place

Finish setting up keystone

35

Authenticate

36

$ openstack --os-auth-type v3samlpassword \ --os-auth-url http://sp.keystone.demo/identity/v3 \ --os-identity-provider demoidp \ --os-identity-provider-url \ https://idp.saml.demo/idp/profile/SAML2/SOAP/ECP \ --os-protocol saml2 \ --os-username username \ --os-password s3cret \ token issue

Authenticate

37

Keystone as an IdP

38

Setup horizon

● Set WEBSSO = True● Add a protocol to WEBSSO_CHOICES

WEBSSO_CHOICES = ( ("credentials", "Keystone credentials"), ("saml2", "External Identity Provider"))

Set up horizon on your keystone IdP, not the SP.It will work without any other configuration.

39

Install xmlsec1

Set up your keystone IdP

40

Set [saml] parameters:

[saml]idp_entity_id=http://idp.keystone.demo/idpidp_sso_endpoint=http://irrelevantcertfile=/etc/keystone/ssl/certs/signing_cert.pemkeyfile=/etc/keystone/ssl/private/signing_key.pemidp_metadata_path=/etc/keystone/saml2_idp_metadata.xml

Set up your keystone IdP

41

Generate a self-signed key pair

Generate metadata

$ keystone-manage saml_idp_metadata > \ /etc/keystone/saml2_idp_metadata.xml

Set up your keystone IdP

42

Create a service provider resource in your keystone IdP:

$ openstack service provider create keystonesp \--auth-url "http://sp.keystone.demo/identity/v3/OS-FEDERATION/identity_providers/keystoneidp/protocols/saml2/auth" \--service-provider-url \http://sp.keystone.demo/Shibboleth.sso/SAML2/ECP

You don't need to add your SP's metadata to the IdP, because there is no exchange happening

Set up your keystone IdP

43

Configure your SAML2.0 Apache auth mod.

Add a federated auth path to the Apache vhost:

<Location /identity/v3/OS-FEDERATION/identity_providers/keystoneidp/protocols/saml2/auth> AuthType shibboleth Require valid-user ShibRequestSetting requireSession 1 ShibExportAssertion Off</Location>

Upload the metadata you generated for your IdP to your SP.

Set up your keystone SP

44

Add your new identity provider, a new mapping, and a new protocol for this IdP

$ openstack identity provider create keystoneidp \ --remote-id https://idp.keystone.demo/idp$ openstack mapping create k2kmap \ --rules rulesk2k.json$ openstack federation protocol create saml2 \ --mapping k2kmap \ --identity-provider keystoneidp

Set up your keystone SP

45

NOTE: as of right now, mod_auth_mellon has a bug that prevents it from being a proper SP in a keystone-to-keystone setup. Use mod_auth_shib instead.

For shibboleth, you'll need to allow these attributes to be passed through from the IdP, set them in attribute-map.xml: <Attribute name="openstack_user" id="openstack_user"/> <Attribute name="openstack_roles" id="openstack_roles"/> <Attribute name="openstack_project" id="openstack_project"/> <Attribute name="openstack_user_domain" id="openstack_user_domain"/> <Attribute name="openstack_project_domain" id="openstack_project_domain"/>

Set up your keystone SP

46

Authenticate

47

Authenticate

$ openstack \--os-service-provider keystonesp \ --os-remote-project-name demo \ --os-remote-project-domain-name Default \token issue

48

● Mappings map attributes found in the user assertion to properties of the keystone user

● Example: map the username attribute

More on mappings

{ "rules": [ { "local": [ { "user": { "name": "{0}" } } ], "remote": [ { "type": "REMOTE_USER" } ] } ]}

49

● Mappings are used to establish authorization for users● Example: map the user to a group that has roles on projects

More on mappings

{ "rules": [ { "local": [ { "user": { "name": "{0}" }, "group": { "name": "federated_users", "domain": { "name": "Default" } } ], "remote": [ { "type": "REMOTE_USER" } ] } ]}

50

● Sometimes users don't map naturally to groups● We can autoprovision projects for them:

More on mappings

{ "rules": [ { "local": [ {"user": { "name": "{0}" }}, { "projects": { "name": "Project for {0}", "roles": [{ "name": "Member" }] } } ], "remote": [{ "type": "REMOTE_USER" }] } ]}

51

● We can use conditions to map a variable set of attributes● any_one_of and not_any_of produce booleans: they aren't

passed into the local rules

More on mappings

{ "rules": [ { "local": [ { "user": { "name": "{0}" }, "group": { "name": "authorized_users", "domain": { "name": "Default" } } ], "remote": [ { "type": "REMOTE_USER" }, { "type": "REMOTE_GROUPS", "any_one_of": [ "employees", "contractors" ] } ]}]}

52

● whitelist and blacklist result in lists that are passed to local rules

More on mappings

{ "rules": [ { "local": [ { "user": { "name": "{0}" }, "group": { "name": "{1}", "domain": { "name": "Default" } } ], "remote": [ { "type": "REMOTE_USER" }, { "type": "REMOTE_GROUPS", "whitelist": [ "employees", "contractors" ] } ]}]}

53

$ cat input.txtREMOTE_USER: user@example.com$ keystone-manage mapping_engine \ --rules rules.json --input input.txt { "group_ids": [], "user": { "domain": {"id": "Federated"}, "type": "ephemeral", "name": "user@example.com" }, "projects": [], "group_names": [{ "domain": {"name": "Default"}, "name": "federated_users" }]}

Checking your mappings

54

● Native SAML - no more Apache configuration● More functional testing● Improved flexibility around protocol configuration, especially with

configuring remote_id_attribute● Improved client support

● What do YOU want to see?

Future improvements

Colleen Murphy ~ @_colleenm ~ cmurphy#openstack-keystone

Questions?