Open Stack

Just following up on this mailing list item ... we discussed at the edge-computing weekly meeting.

Summary:

·         FAILURE SCENARIO

o    EDGE CLOUD and all its LOCAL Users/Clients (e.g. CLI running on cloud or adjacent workstation),
have LOST CONNECTIVITY to the Central Cloud and the Central Remote Identity Provider


·         If a LOCAL User/Client has already authenticated with the Central Remote Identity Provider and
                                                  already has a signed SAML assertion

o    Then the LOCAL User/Client can use that signed SAML assertion
to create a token with LOCAL Keystone

§  Where LOCAL Keystone can independently validate the signed SAML Assertion
and map to appropriate Keystone objects and create a TOKEN

o    AND
the LOCAL User/Client can then use this TOKEN to proceed with a request to a LOCAL Service.


·         HOWEVER,
If the LOCAL User/Client

o    Does NOT have a signed SAML assertion yet ... or it expired (? Not sure if they can expire ?),
        THEN

o    The LOCAL User/Client can not create a TOKEN.

§  ( unless there are local (i.e. non-federated) users defined ... but seems to defeat the purpose of federation )

So suspect there still are some connectivity failure scenarios that restrict the autonomy of a disconnected Edge Cloud.

*** I would suggest that the testing that we are trying to setup around federated Keystone SHOULD explicitly
        test these connectivity failure scenarios in order to characterize how bad of an issue this is or not.

Let me know if I did not summarize correctly,
Greg.


From: Greg Waines <Greg.Waines at windriver.com>
Date: Tuesday, June 26, 2018 at 7:52 AM
To: Lance Bragstad <lbragstad at gmail.com>, "edge-computing at lists.openstack.org" <edge-computing at lists.openstack.org>
Subject: Re: [Edge-computing] Keystone Edge Architectures

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/20180627/ace0b270/attachment-0001.html>