[Edge-computing] Keystone Edge Architectures

Lance Bragstad lbragstad at gmail.com
Thu Jun 28 16:26:47 UTC 2018



On 06/27/2018 11:30 AM, Waines, Greg wrote:
>
> 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 ?),
>

I should clarify this a bit. Keystone doesn't deal with SAML directly
when it act as a service provider. Instead it uses Apache plugins (e.g.
mod_shib) to do the SAML verification. This is also related to the bit
on the call where Kristi and I talked about how keystone needs to
establish trust with the identity provider. Keystone, specifically
mod_shib and the web server, need to be configured with the certificates
used to validate SAML from the identity provider, which is an
out-of-band process.

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

The concept of replicating data over the API was also brought up towards
the end of the call as a possible solution. The TL;DR is that each
deployment would be independent, but data would be kept in sync by
making API requests that forcibly create entities with the same IDs
(manual replication if you will). This idea has been discussed at length
over the last couple years [0]. We most recently discussed it during the
summit in Sydney.

Where we really tripped was replication of revocation events. For
example, assume you have the ability in keystone to forcibly create
things with specific IDs, allowing you to manually replicate data across
your edge deployments. At the same time you're keeping the fernet keys
in sync, so a user can actually generate tokens in one deployment and
use them in other (since each keystone node has the same IDs for
projects, domains, users, etc..), even though replication isn't
happening at the database. Revocation events are records used internally
by keystone to track events that affect token validity (e.g. a user
changing their password or deleting a specific token), and they are not
exposed via keystone's API. The concern is that without replicating this
table, it would be possible for a user to:

 - generate a token in deployment A
 - use the token in deployment B to do something
 - change their password in deployment A, which creates a revocation
event invalidating the token from step one in deployment A
 - the user attempts to use the token from step one in deployment A but
it is considered invalid (due to the revocation event)
 - the user successfully executes API calls with the token from step one
in deployment B because deployment B has no knowledge of the revocation
event in deployment A

We didn't get into that much detail in the call, but wanted to share
where the conversation ended up the last time we had it.

[0] https://review.openstack.org/#/c/323499/



>  
>
>  
>
> *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/20180628/a7077686/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/edge-computing/attachments/20180628/a7077686/attachment-0001.sig>


More information about the Edge-computing mailing list