use entity of token for scalability

[jmls]

At the moment, it is suggested that the registration endpoints are secured to require an administrator to register a new device. A better workflow would to to

• require a user to sign in using a predefined authentication service (userpass/ldap etc)
• register their device, supplying a meaningful, friendly name for their device
• create this device as an alias on the entity , with a userid relating to the entity and a display_name of the friendly name

(this workflow follows the recommendations on several sites)
https://webauthn.io/
https://doubleoctopus.com/blog/your-complete-guide-to-fido-fast-identity-online/
https://hybrismart.com/2019/05/23/authentication-with-hardware-security-keys-via-webauthn-in-sap-commerce-cloud/

So when they next log in, they have to present their userid and use their device

This workflow would mean that you can drop the requirement for roles, as all policies could be defined on either the entity or entity group . It also removes the requirement for the administrator to be the pinch point (imagine having to manually register a few hundred devices by yourself) and it also then gives the app developer the option to require username and password, username only (passwordless if the device is present)

You could grab the entityId from the token used to access the registration endpoint, thus preventing someone from id spoofing

thoughts ?

[bruj0]

register their device, supplying a meaningful, friendly name for their device

This can be easily a known ID from the first authentication method too because it would also work as the "something you know" part of the current workflow.

So when they next log in, they have to present their userid and use their device

This would convert it to an MFA device for the purpose of Vault authentication.
I've explored this route and it is possible but not by a plugin. By this I mean making the u2f device a new MFA method as understood by Vault, the change most likely would have to be inside Vault

(imagine having to manually register a few hundred devices by yourself) and it also then gives the app developer the option to require username and password, username only (passwordless if the device is present)

This is actually the best reason to make this change.

So the workflow would be like this:

1. User authenticates to the first auth and gets a token and an ID (ie username in userpass)

2. Calls the register endpoint in the u2f auth with the ID (device name) and here is the tricky part. How does the plugin know that the ID actually belongs to the token that is calling the endpoint?

Some auth methods embed this information in the metadata of the token but some don't.
I would have to do some research but this definitely would be possible without modifying Vault itself like the MFA method.

So there are 3 objectives to this change:

1. Make it identity-aware, ie be able to inherit policies from a group.
2. Make the registering of the device self-managed
3. Replace the device name with an ID previously authenticated, ie by userpass

Thanks for the feedback, I will definitely do some research on this.

[jmls]

This can be easily a known ID from the first authentication method too because it would also work as the "something you know" part of the current workflow.

There may be an issue with this. The ID of the entity or alias is a guid (which is hard to remember ;) ) The other problem is that the user may have multiple hardware tokens (work, home, mobile) but wants to log into the same entity in vault.

So, the initial login (userpass) gives us the entity (as part of the token) The user then registers token A (calling it home_pc_token) . Internally, the device name could be entity_id+token_name. The user goes on to register tokens B and C

When logging in, they enter their entity username and choose the device they want to use (I believe that the browser credentials api can do this), or just enter the device name. In the plugin, we find the entity using their name, then grab the entity Id and combine that with the device name to get the actual "device".

[bruj0]

The ID of the entity or alias is a guid (which is hard to remember ;) )

Yes, the GUID is a perfect solution and we could ask the user to choose a "friendly" name that will be linked internally with this guide.

So, the initial login (userpass) gives us the entity (as part of the token) The user then registers token A (calling it home_pc_token) . Internally, the device name could be entity_id+token_name. The user goes on to register tokens B and C

Yes the relation guid to the device name I was mentioning.

The other problem is that the user may have multiple hardware tokens (work, home, mobile) but wants to log into the same entity in vault.

This is not a big problem more like a new feature: Support multiple u2f tokens per user.

[jmls]

@bruj0 just asking if there's been any progress or further ideas on this ? ;)

[jmls]

@bruj0 I'm still lurking - did you get anywhere with the research ? ·.