Open Stack

Thanks Lance ... this clears up my general confusion.
So it sounds like user authentication can be performed by the edge keystone, even when it does not currently have connectivity to the remote identity provider.

So ... just a few clarifying questions so I understand at high-level how this works.

Is the following correct flow of events on the Edge Cloud?
( note have some embedded questions as well )


·         Some time during configuration or initial connectivity (?) with the remote Federated Identity Provider,
the Edge Cloud Keystone gets CERTIFICATE(s) of the remote Federated Identity Provider,

o    I assume that these CERTIFICATE(s) can be updated as well by Federated Identity Provider
as certs expire or change,


·         Also at configuration time or initial connectivity,
I assume there is also a set of SAML --> OpenStack User/Tenant/Role MAPPINGs that get configured
on the Edge Cloud,   (Correct ?)


·         A LOCAL user/client to the Edge Cloud, when sending an authenticated REST API Request,
first gets a token from the LOCAL Keystone by sending a Token Request to the LOCAL Keystone
with a ‘signed’ SAML doc as the user authentication information

o    The LOCAL keystone uses the CERTIFICATE(s) (of the federated identity provider) that it has,
to validate the SAML doc is authentic, and

o    Then uses the info in the SAML doc to convert to the associated OpenStack User/Tenant/Role , and

o    Then generates the appropriate local token.

o    CORRECT ?



o    QUESTIONS

§  How does the LOCAL user/client get the ‘signed’ SAML doc ?

·         ? does this required connectivity to remote Federated Identity Provider ?


Greg.



From: Lance Bragstad <lbragstad at gmail.com>
Date: Monday, June 25, 2018 at 4:26 PM
To: "edge-computing at lists.openstack.org" <edge-computing at lists.openstack.org>
Subject: [Edge-computing] Keystone Edge Architectures

Hi Greg,

Jumping in a bit late, but I can try and clear up some of the questions
around keystone's federated identity implementation.

Your initial assessment of federated identity is accurate where each
keystone node in the deployment refers to an external identity provider
as the source of truth for user identities. But, keystone doesn't
actively reach out to the external identity provider at authentication
time. Instead, a user presents keystone (which is acting as a service
provider) with a SAML document that keystone will verify with a set of
certificates from the identity provider. If keystone can prove the SAML
assertion came from a trusted identity provider, it processes the
attributes through a mapping engine, which essentially translates the
SAML assertion into OpenStack-specific terminology.

The actual validation of the SAML assertion doesn't require a connection
to the identity provider that issued it. This trust relationship is
established when setting up federated identity via configuration (e.g.
these are the certs for the identity provider that I trust).

Hopefully that helps

Lance


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/edge-computing/attachments/20180626/a57f13b9/attachment.html>