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: [email protected]$ keystone-manage mapping_engine \ --rules rules.json --input input.txt { "group_ids": [], "user": { "domain": {"id": "Federated"}, "type": "ephemeral", "name": "[email protected]" }, "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?
Top Related