[openstack-dev] [barbican] Secret entity constraints
John Wood
john.wood at RACKSPACE.COM
Tue May 14 18:37:30 UTC 2013
Hello folks,
Just curious what constants we should consider for creating secrets in Barbican.
Currently the only non-nullable attribute on a 'secret' entity is its mime-type, used to specify the format the secret data is formatted in. Should the mime-type have a default value if not specified, say of 'text/plain', or else should clients POSTing new secrets always have to specify the mime-type? Malini also brought up this one: if a default value is desired, should the mime-type be a config file option, or else a tenant/user-specific default value, or a default keyed to the secret type specified?
Multiple secrets can have the same name (or no name currently). After discussion with Jarret, it makes sense to enforce a non-null, non-empty name for a secret, as this could get confusing on a UI display of a tenant's secrets. This name is convenience info about a secret, so it seems duplicate names would be acceptable.
The expiration date can optionally be specified (null implying the secret never expires). We've previously discussed not returning expired secrets in GET calls. This all seems fine to do, but are there any issues with this approach?
If the algorithm, bit-length, and/or cypher-type are not specified, then more sophisticated validation will not be possible. Should it be OK for a client to not specify these parameters to save a secret? It seems this should be allowed, with only the mime-type of the secret data verified by Barbican.
Thanks,
John
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
More information about the OpenStack-dev
mailing list