Open Stack

Hi Subbu,

The Ephemeral Token work has been pushed to Juno because of timelines and the need to get the revocation API in place first. I fully expect that the ephemeral tokens, and other related improvements will be part of Juno as a lot of the work has already been spec’d out / started.

Cheers,
Morgan
—
Morgan Fainberg
Principal Software Engineer
Core Developer, Keystone
m at metacloud.com


On March 12, 2014 at 13:57:44, Subbu Allamaraju (subbu at subbu.org) wrote:

Adam - can you comment if the status of ephemeral tokens. All commits for https://blueprints.launchpad.net/keystone/+spec/ephemeral-pki-tokens have been abandoned.

Thanks
Subbu


On Wed, Feb 19, 2014 at 8:50 PM, Adam Young <ayoung at redhat.com> wrote:
On 02/19/2014 07:00 PM, Miller, Mark M (EB SW Cloud - R&D - Corvallis) wrote:
Hello,

I read the following and want to register a disagreement:

"With token revocation events in place, we no longer have a need to store a token revocation list. The token revocation list is the primary reason why keystone bothers to persist PKI tokens, so without it, PKI tokens can become completely ephemeral."

One idea behind PKI tokens is to enable services to parse the token to retrieve role/project/domain data for a particular user without having to validate the token with Keystone each and every time. In order to make sure that the token has not been revoked, services need to check the expiration date and "check the token revocation list" to make sure that the token is still valid. That said, how will non-OpenStack services obtain token revocation information if the revocation list is removed?

Going to be replcaed with an API for listing revocation events.

https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3-os-revoke-ext.md


I thought maybe the new "Callbacks on internal events" might be something external services could use like listening in onto a Keystone message queue, but it apparently only applies to extensions.

Actually, it is just the opposite:  internal events are callbacks that are not shipped outside of Keystone, but rather from one infrastructure piece to another.  In this case, things that can trigger revoaction events, like disable a domain.  This event is published externally as an update event, but the focused disable is internal only.



This is one time I will be glad to be wrong.

Regards,

Mark

_______________________________________________
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to     : openstack at lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


_______________________________________________
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to     : openstack at lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

_______________________________________________  
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack  
Post to : openstack at lists.openstack.org  
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140312/3f7f726d/attachment.html>