Demystifying Identity Federation. Colleen Murphy ~ cmurphy

Transcription

1 Demystifying Identity Federation Colleen Murphy ~ cmurphy

2 About me Cloud developer at SUSE Keystone core reviewer 2

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 3

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. 4

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. 5

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. 6

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. 7

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) 8

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. 9

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: 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 10

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 11

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 12

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 13

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. 14

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) 15

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 16

17 Normal keystone 17

18 SAML2.0 WebSSO 18

19 SAML2.0 ECP 19

20 WebSSO with keystone and horizon 20

21 Keystone to Keystone 21

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 22

23 Demo time 23

24 Keystone with an external IdP 24

25 Have an identity provider For this demo I used this node.js app: 25

26 Setup horizon Set WEBSSO = True Add a protocol to WEBSSO_CHOICES WEBSSO_CHOICES = ( ("credentials", "Keystone credentials"), ("saml2", "My Awesome IdP") ) 26

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 27

28 Set up Apache Install the mod_shib package (or the equivalent for your distro) 28

29 Set up Apache Add protected Locations to your apache vhost 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> 29

30 Generate keys # shib-keygen 30

31 Configure metadata Edit /etc/shibboleth/shibboleth2.xml <ApplicationDefaults entityid=" REMOTE_USER="eppn persistent-id targeted-id"> #... <SSO entityid="urn:example:idp"> #... <MetadataProvider type="xml" file="/etc/shibboleth/idp.saml.demo.xml" /> 31

32 Exchange metadata Install the IdP s metadata at the location you configured: <MetadataProvider type="xml" file="/etc/shibboleth/idp.saml.demo.xml" /> 32

33 Configure metadata Restart shibd and apache: # systemctl restart shibd apache2 Download metadata: $ wget \ 33

34 Finish setting up keystone 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 34

35 Authenticate 35

36 Authenticate $ openstack --os-auth-type v3samlpassword \ --os-auth-url \ --os-identity-provider demoidp \ --os-identity-provider-url \ \ --os-protocol saml2 \ --os-username username \ --os-password s3cret \ token issue 36

37 Keystone as an IdP 37

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. 38

39 Set up your keystone IdP Install xmlsec1 39

40 Set up your keystone IdP Set [saml] parameters: [saml] idp_entity_id= idp_sso_endpoint= certfile=/etc/keystone/ssl/certs/signing_cert.pem keyfile=/etc/keystone/ssl/private/signing_key.pem idp_metadata_path=/etc/keystone/saml2_idp_metadata.xml 40

41 Set up your keystone IdP Generate a self-signed key pair Generate metadata $ keystone-manage saml_idp_metadata > \ /etc/keystone/saml2_idp_metadata.xml 41

42 Set up your keystone IdP Create a service provider resource in your keystone IdP: $ openstack service provider create keystonesp \ --auth-url " /OS-FEDERATION/identity_providers /keystoneidp/protocols/saml2/auth" \ --service-provider-url \ You don't need to add your SP's metadata to the IdP, because there is no exchange happening 42

43 Set up your keystone SP 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. 43

44 Set up your keystone SP Add your new identity provider, a new mapping, and a new protocol for this IdP $ openstack identity provider create keystoneidp \ --remote-id $ openstack mapping create k2kmap \ --rules rulesk2k.json $ openstack federation protocol create saml2 \ --mapping k2kmap \ --identity-provider keystoneidp 44

45 Set up your keystone SP 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"/> 45

46 Authenticate 46

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

48 More on mappings Mappings map attributes found in the user assertion to properties of the keystone user Example: map the username attribute { } "rules": [ { "local": [ { "user": { "name": "{0}" } } ], "remote": [ { "type": "REMOTE_USER" } ] } ] 48

49 More on mappings Mappings are used to establish authorization for users Example: map the user to a group that has roles on projects { } "rules": [ { "local": [ { "user": { "name": "{0}" }, "group": { "name": "federated_users", "domain": { "name": "Default" } } ], "remote": [ { "type": "REMOTE_USER" } ] } ] 49

50 More on mappings Sometimes users don't map naturally to groups We can autoprovision projects for them: { } "rules": [ { "local": [ {"user": { "name": "{0}" }}, { "projects": { "name": "Project for {0}", "roles": [{ "name": "Member" }] } } ], "remote": [{ "type": "REMOTE_USER" }] } ] 50

51 More on mappings 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 { "rules": [ { "local": [ { "user": { "name": "{0}" }, "group": { "name": "authorized_users", "domain": { "name": "Default" } } ], "remote": [ { "type": "REMOTE_USER" }, { "type": "REMOTE_GROUPS", "any_one_of": [ "employees", "contractors" ] } ]} ]} 51

52 More on mappings whitelist and blacklist result in lists that are passed to local rules { "rules": [ { "local": [ { "user": { "name": "{0}" }, "group": { "name": "{1}", "domain": { "name": "Default" } } ], "remote": [ { "type": "REMOTE_USER" }, { "type": "REMOTE_GROUPS", "whitelist": [ "employees", "contractors" ] } ]} ]} 52

53 Checking your mappings $ cat input.txt REMOTE_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" }] 53

54 Future improvements 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? 54

55 Questions? Colleen Murphy ~ cmurphy #openstack-keystone