Bridging Clouds with Keystone to Keystone Federation Vishakha - PowerPoint PPT Presentation

Bridging Clouds with Keystone to Keystone Federation Vishakha Agarwal Colleen Murphy

Who are we? • Vishakha Agarwal (vishakha) • Senior Member Technical Staff at NEC • Keystone contributor • Colleen Murphy (cmurphy) • Cloud Developer at SUSE • Keystone PTL

Overview What is federated identity? What is Keystone to Keystone federation? History of Keystone to Keystone Terminology Auth flows Configuration Demonstration What's next?

What is federated identity? A shared, trusted source of identity information and means of authentication external to the keystone service.

What is Keystone to Keystone federation? Keystone acts as the trusted source and means of authentication to another keystone instance.

History of Keystone to Keystone • Federation implemented in Icehouse • K2K implemented in Kilo • Created primarily for cloud bursting scenarios • Also for in-house multi-site deployments

Modern use cases for K2K • Multi-site • Edge computing

Terminology • Identity Provider (IdP) • The thing that accepts your credentials, validates them, and generates a yay/nay response. • Service Provider (SP) • The thing with the resource we need. • For keystone, the service it provides is the tokens that we use on other OpenStack services. In a Keystone to Keystone configuration, one keystone instance is an IdP and one is an SP. They could also EACH be both an IdP and an SP!

Terminology • SAML2.0 • an XML-based federation protocol. • Assertion • a formatted statement from the Identity Provider that asserts that a user is authenticated and provides some attributes about the user.

Federation in Keystone • Shadow users • Keystone's local copy of a remote user's attributes • Allows for consistent handling of users coming from different sources, especially with regard to role assignments • Mapping Rules • Keystone's JSON API map attributes from a SAML assertion to attributes of a local keystone user • Handles both user identity (e.g. username) and authorization (group membership or auto-provisioned role assignments)

SAML2.0 Profiles • WebSSO • the basic SAML2.0 auth flow profile, involving a web browser • NOT used for K2K • ECP • SAML2.0 auth flow profile without a browser • K2K uses a modified form of this

WebSSO Auth Flow

Keystone to Keystone Auth Flow

Setup keystone to keystone Federation ● Start with two keystone installations, one for the Service Provider and one for the Identity Provider ● Configure horizon for the Identity Provider ● See the install guide https://docs.openstack.org/keystone/latest/install/ ● Tip: enable insecure_debug in keystone.conf to help debug auth attempts during set up (disable for production!)

Configure Keystone as Identity Provider ● Install xmlsec1 and generate PKI key-pair. ● Configure the SAML2.0 Identity Provider metadata in keystone.conf. ○ idp_entity_id ○ idp_sso_endpoint ● Generate metadata for Identity Provider through keystone-manage.

Configure Keystone as Identity Provider ● Add more keys to keystone conf file ○ certfile and keyfile. ○ metadata of IDP ● For instance - vi /etc /keystone/keystone.conf [ 𝚝𝚋𝚗𝚖 ] 𝚓𝚎𝚚 _ 𝚏𝚘𝚞𝚓𝚞𝚣 _ 𝚓𝚎 = 𝚒𝚞𝚞𝚚 :// 𝚓𝚎𝚚 . 𝚕𝚏𝚣𝚝𝚞𝚙𝚘𝚏 . 𝚎𝚏𝚗𝚙 / 𝚓𝚎𝚚 𝚓𝚎𝚚 _ 𝚝𝚝𝚙 _ 𝚏𝚘𝚎𝚚𝚙𝚓𝚘𝚞 = 𝚒𝚞𝚞𝚚 :// 𝚓𝚜𝚜𝚏𝚖𝚏𝚠𝚋𝚘𝚞 𝚍𝚏𝚜 t 𝚐𝚓𝚖𝚏 = / 𝚏𝚞𝚍 / 𝚕𝚏𝚣𝚝𝚞𝚙𝚘𝚏 / 𝚝𝚝𝚖 / 𝚍𝚏𝚜𝚞𝚝 / 𝚝𝚓𝚑𝚘𝚓𝚘𝚑 _ 𝚍𝚏𝚜𝚞 . 𝚚𝚏𝚗 𝚕𝚏𝚣𝚐𝚓𝚖𝚏 = / 𝚏𝚞𝚍 / 𝚕𝚏𝚣𝚝𝚞𝚙𝚘𝚏 / 𝚝𝚝𝚖 / 𝚚𝚜𝚓𝚠𝚋𝚞𝚏 / 𝚝𝚓𝚑𝚘𝚓𝚘𝚑 _ 𝚕𝚏𝚣 . 𝚚𝚏𝚗 𝚓𝚎𝚚 _ 𝚗𝚏𝚞𝚋𝚎𝚋𝚞𝚋 _ 𝚚𝚋𝚞𝚒 = / 𝚏𝚞𝚍 / 𝚕𝚏𝚣𝚝𝚞𝚙𝚘𝚏 / 𝚝𝚋𝚗𝚖𝟹 _ 𝚓𝚎𝚚 _ 𝚗𝚏𝚞𝚋𝚎𝚋𝚞𝚋 . 𝚢𝚗𝚖

Configure Keystone as Service Provider ● Create an identity provider resource with same entity id we configured in the IDP (Here Remote ID is same as entityID of IDP) $ 𝚙𝚚𝚏𝚘𝚝𝚞𝚋𝚍𝚕 𝚓𝚎𝚏𝚘𝚞𝚓𝚞𝚣 𝚚𝚜𝚙𝚠𝚓𝚎𝚏𝚜 𝚍𝚜𝚏𝚋𝚞𝚏 \ -- 𝚜𝚏𝚗𝚙𝚞𝚏 - 𝚓𝚎 𝚒𝚞𝚞𝚚 :// 𝚓𝚎𝚚 . 𝚕𝚏𝚣𝚝𝚞𝚙𝚘𝚏 . 𝚎𝚏𝚗𝚙 / 𝚓𝚎𝚚 𝚕𝚏𝚣𝚝𝚞𝚙𝚘𝚏𝚓𝚎𝚚 Note - We can grep the remote id by making curl request to its metadata endpoint. $ 𝚍𝚟𝚜𝚖 - 𝚝 𝚒𝚞𝚞𝚚 :// 𝚓𝚎𝚚 . keystone . 𝚎𝚏𝚗𝚙 /v3/OS-FEDERATION/saml2/metadata | 𝚑𝚜𝚏𝚚 𝚏𝚘𝚞𝚓𝚞𝚣𝙹𝙴 < 𝙵𝚘𝚞𝚓𝚞𝚣𝙴𝚏𝚝𝚍𝚜𝚓𝚚𝚞𝚙𝚜 𝚏𝚘𝚞𝚓𝚞𝚣𝙹𝙴 =" 𝚟𝚜𝚘 : 𝚏𝚢𝚋𝚗𝚚𝚖𝚏 : 𝚓𝚎𝚚 " 𝚢𝚗𝚖𝚘𝚝 =" 𝚟𝚜𝚘 : 𝚙𝚋𝚝𝚓𝚝 : 𝚘𝚋𝚗𝚏𝚝 : 𝚞𝚍 : 𝚃𝙱𝙽𝙼 : 𝟹 .0: 𝚗𝚏𝚞𝚋𝚎𝚋𝚞𝚋 "> ● Create the group “federated_users” locally to which remote users will be mapped and assign it with some role on a project. $ 𝚙𝚚𝚏𝚘𝚝𝚞𝚋𝚍𝚕 𝚑𝚜𝚙𝚟𝚚 𝚍𝚜𝚏𝚋𝚞𝚏 𝚐𝚏𝚎𝚏𝚜𝚋𝚞𝚏𝚎 _ 𝚟𝚝𝚏𝚜𝚝 $ 𝚙𝚚𝚏𝚘𝚝𝚞𝚋𝚍𝚕 𝚜𝚙𝚖𝚏 𝚋𝚎𝚎 -- 𝚑𝚜𝚙𝚟𝚚 𝚐𝚏𝚎𝚏𝚜𝚋𝚞𝚏𝚎 _ 𝚟𝚝𝚏𝚜𝚝 -- 𝚚𝚜𝚙𝚔𝚏𝚍𝚞 𝚋𝚎𝚗𝚓𝚘 𝚋𝚎𝚗𝚓𝚘

● Create a JSON file for rules defining the Remote parameter mapped to local. [ { "local" : [ { "user" : { "name" : "{0}" }, "group" : { "domain" : { "name" : "Default" }, "name" : "federated_users" } } ], "remote" : [ { "type" : "openstack_user" } ] } ]

Configure Keystone as Service Provider ● Create mapping $ 𝚙𝚚𝚏𝚘𝚝𝚞𝚋𝚍𝚕 𝚗𝚋𝚚𝚚𝚓𝚘𝚑 𝚍𝚜𝚏𝚋𝚞𝚏 -- 𝚜𝚟𝚖𝚏𝚝 𝚜𝚟𝚖𝚏𝚝 . 𝚔𝚝𝚙𝚘 𝚕𝟹𝚕𝚗𝚋𝚚 ● Create Federation Protocol $ 𝚙𝚚𝚏𝚘𝚝𝚞𝚋𝚍𝚕 𝚐𝚏𝚎𝚏𝚜𝚋𝚞𝚓𝚙𝚘 𝚚𝚜𝚙𝚞𝚙𝚍𝚙𝚖 𝚍𝚜𝚏𝚋𝚞𝚏 𝚝𝚋𝚗𝚖𝟹 \ -- 𝚗𝚋𝚚𝚚𝚓𝚘𝚑 𝚕𝟹𝚕𝚗𝚋𝚚 \ -- 𝚓𝚎𝚏𝚘𝚞𝚓𝚞𝚣 - 𝚚𝚜𝚙𝚠𝚓𝚎𝚏𝚜 𝚕𝚏𝚣𝚝𝚞𝚙𝚘𝚏𝚓𝚎𝚚

Configure Keystone as Service Provider ● Install apache shibboleth and generate keys. ● Edit shibboleth2.xml ○ Entity id of IDP ○ Entity id of SP ○ Metadata URL of Idp ● Adding the attribute to attribute-map.xml ● Check /var/log/shibboleth/shibd.log and /var/log/shibboleth/shibd_warn.log for errors or warnings.

Configure Keystone as Service Provider ● Changing the vhost file of keystone. vi /etc/apache2/sites-available/keystone-wsgi-public.conf < 𝙼𝚙𝚍𝚋𝚞𝚓𝚙𝚘 / 𝚃𝚒𝚓𝚌𝚌𝚙𝚖𝚏𝚞𝚒 . 𝚝𝚝𝚙 > 𝚃𝚏𝚞𝙸𝚋𝚘𝚎𝚖𝚏𝚜 𝚝𝚒𝚓𝚌 </ 𝙼𝚙𝚍𝚋𝚞𝚓𝚙𝚘 > < 𝙼𝚙𝚍𝚋𝚞𝚓𝚙𝚘 / 𝚠𝟺 / 𝙿𝚃 - 𝙶𝙵𝙴𝙵𝚂𝙱𝚄𝙹𝙿𝙾 / 𝚓𝚎𝚏𝚘𝚞𝚓𝚞𝚣 _ 𝚚𝚜𝚙𝚠𝚓𝚎𝚏𝚜𝚝 / 𝚕𝚏𝚣𝚝𝚞𝚙𝚘𝚏𝚓𝚎𝚚 / 𝚚𝚜𝚙𝚞𝚙𝚍𝚙𝚖𝚝 / 𝚝𝚋𝚗𝚖𝟹 / 𝚋𝚟𝚞𝚒 > 𝚃𝚒𝚓𝚌𝚂𝚏𝚛𝚟𝚏𝚝𝚞𝚃𝚏𝚞𝚞𝚓𝚘𝚑 𝚜𝚏𝚛𝚟𝚓𝚜𝚏𝚃𝚏𝚝𝚝𝚓𝚙𝚘 𝟸 𝙱𝚟𝚞𝚒𝚄𝚣𝚚𝚏 𝚝𝚒𝚓𝚌𝚌𝚙𝚖𝚏𝚞𝚒 𝚃𝚒𝚓𝚌𝙵𝚢𝚚𝚙𝚜𝚞𝙱𝚝𝚝𝚏𝚜𝚞𝚓𝚙𝚘 𝙿𝚐𝚐 𝚂𝚏𝚛𝚟𝚓𝚜𝚏 𝚠𝚋𝚖𝚓𝚎 - 𝚟𝚝𝚏𝚜 < 𝙹𝚐𝚆𝚏𝚜𝚝𝚓𝚙𝚘 < 𝟹 . 𝟻 > 𝚃𝚒𝚓𝚌𝚂𝚏𝚛𝚟𝚓𝚜𝚏𝚃𝚏𝚝𝚝𝚓𝚙𝚘 𝙿𝚘 𝚃𝚒𝚓𝚌𝚂𝚏𝚛𝚟𝚓𝚜𝚏𝙱𝚖𝚖 𝙿𝚘 </ 𝙹𝚐𝚆𝚏𝚜𝚝𝚓𝚙𝚘 > </ 𝙼𝚙𝚍𝚋𝚞𝚓𝚙𝚘 >

Configure Keystone as Service Provider ● SP Keystone should know about a federated login. ○ auth method For instance - vi /etc/keystone/keystone.conf [ 𝚋𝚟𝚞𝚒 ] 𝚗𝚏𝚞𝚒𝚙𝚎𝚝 = 𝚚𝚋𝚝𝚝𝚡𝚙𝚜𝚎 , 𝚞𝚙𝚕𝚏𝚘 , 𝚝𝚋𝚗𝚖𝟹