Keyname for certificates should be consistently handled and editable once entity exists

[canariecaf]

This challenge is is related to responding to the SAMLJ issue mentioned here http://shibboleth.net/community/advisories/secadv_20150225.txt where those who produce metadata should populate 'Keyname' with each of their entities records. Today, Jagger does not do that and is not as consistent as it could be around keyname elements :(

Right now,IF Keyname element in SAML metadata is available when an entity is created via metadata fragment or loaded via the import process it will exist and be used (nice!)

HOWEVER, if one wants to ADD a keyname value to an existing certificate or examine the existing certificate and use the existing keyname that should agree with the certificate (ie populate keyname from existing cert), it cannot be done in Jagger at this time.

Right now this means that in order to add keynames to existing entities one has these possible scenarios:
-- identify what you should edit in the Mysql schema and perform an edit there (very difficult, and not explored by this issue submitter yet)
-- with only using the web interface AND the entity is static, edit the static metadata
-- with only using the web interface AND the entity is locally managed, view the metadata, cut and paste it, edit in keyname manually, DELETE the entity, and recreate it.

A preferred experience would be:

For entities that exist without a keyname to have some way to add the field.
Also have the option of importing the keyname based of the cn and Subject Alternatenames of the entity's certificate (there may be more than one keyname)

[Edugate]

Hi Chris,
Keyname was available before but it was requested to be hide by FaaS
I will discuss it with guys (Marina/Peter) .
I'll get back to you later.

All the best,
Janusz

On 20/04/15 16:32, Canadian Access Federation wrote:

This challenge is is related to responding to the SAMLJ issue mentioned
here http://shibboleth.net/community/advisories/secadv_20150225.txt
where those who produce metadata should populate 'Keyname' with each of
their entities records. Today, Jagger does not do that and is not as
consistent as it could be around keyname elements :(

Right now,IF Keyname element in SAML metadata is available when an
entity is created via metadata fragment or loaded via the import process
it will exist and be used (nice!)

HOWEVER, if one wants to /ADD/ a keyname value to an existing
certificate or examine the existing certificate and use the existing
keyname that should agree with the certificate (ie populate keyname from
existing cert), it cannot be done in Jagger at this time.

Right now this means that in order to add keynames to existing entities
one has these possible scenarios:
-- identify what you should edit in the Mysql schema and perform an edit
there (very difficult, and not explored by this issue submitter yet)
-- with only using the web interface AND the entity is static, edit the
static metadata
-- with only using the web interface AND the entity is locally managed,
view the metadata, cut and paste it, edit in keyname manually, DELETE
the entity, and recreate it.

A preferred experience would be:

For entities that exist without a keyname to have some way to add the field.
Also have the option of importing the keyname based of the cn and
Subject Alternatenames of the entity's certificate (there may be more
than one keyname)

—
Reply to this email directly or view it on GitHub
#184.

Janusz Ulanowski
Edugate: http://www.edugate.ie
HEAnet Limited, Ireland's Education and Research Network
1st Floor, 5 George's Dock, IFSC, Dublin 1
Registered in Ireland, no 275301

[canariecaf]

Thanks.
May I recommend that maybe a switch be enabled to allow the ability to at least edit keyname and that previous functionality (even if it doesn't match above suggested workflow) be enabled.

I understand and appreciate the desire to mask it. I would also consider accepting a keyname that ONLY aligned with the certificate and that it was uneditable in the model. In that case, I would open the entity, it would populate the field and I would click save (a locally managed one of course!).

I think this statement from the security advisory captures why it is being asked for and believe other users of the Jagger would desire and benefit from it as well:

"If metadata in use with a MetadataPKIX- trust engine is not under the
control of the IdP (e.g. is published by a federation), the federation
or publisher would need to take the necessary steps outlined above to
ensure that all RoleDescriptors have at least 1 KeyDescriptor/KeyName."

If the request is not easily actioned, can you confirm how I can manually edit the keyname either via SQL commands or strategically for locally managed entities? My suggestions above are just me guestimating how it could be done.

Many thanks in advance.

C