Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PIV verification status communicated to remote realms #33

Closed
vmalguy opened this issue Nov 5, 2020 · 6 comments · Fixed by #143
Closed

PIV verification status communicated to remote realms #33

vmalguy opened this issue Nov 5, 2020 · 6 comments · Fixed by #143
Labels
feature This is a new feature request

Comments

@vmalguy
Copy link

vmalguy commented Nov 5, 2020

In a multi-realm deployment infra, remote realm should send PIV informations to the local bastion.
This could be use to enforce local Multi-Factor Authentication policies even for realm users.

@speed47 speed47 added the feature This is a new feature request label Nov 5, 2020
@Alkorin
Copy link
Member

Alkorin commented Nov 5, 2020

PIV doesn't mean MFA. It only proves that the private key is stored in a secure physical device.

Do you need MFA aswell ?

@speed47
Copy link
Collaborator

speed47 commented Nov 5, 2020

Interesting use case. I think the remote bastion can also pass some more information to the local one, such as:

  • Was MFA enabled for this user?
  • Is it a PIV-enforced user ?

Then on the local bastion, you might be able to specify some policies that will be enforced, something along the lines of:

realmModify --realm eu --piv-policy enforce

... which would deny any remote user not having PIV enforced on his local bastion

@vmalguy
Copy link
Author

vmalguy commented Nov 5, 2020

PIV doesn't mean MFA. It only proves that the private key is stored in a secure physical device.

Do you need MFA aswell ?

anything that could help enforce access policies

Interesting use case. I think the remote bastion can also pass some more information to the local one, such as:

  • Was MFA enabled for this user?
  • Is it a PIV-enforced user ?

Then on the local bastion, you might be able to specify some policies that will be enforced, something along the lines of:

realmModify --realm eu --piv-policy enforce

... which would deny any remote user not having PIV enforced on his local bastion

When it come to PIV, I like some flexibility.
Per realm is good but how about also per group or host or user ?

@Alkorin
Copy link
Member

Alkorin commented Nov 5, 2020

Per realm is good but how about also per group or host or user ?

The main goal of realm is to not have the notion of user in the local bastion. Authentication is delegated to the distant bastion.
But we could have this check on groups so that a distant user can't use the group if he didn't used its PIV key to connect to the distant bastion.

@speed47
Copy link
Collaborator

speed47 commented Nov 5, 2020

Could be done too, even if it would be a bit more complex:

realm-wide setting:

realmModify --realm eu --piv-policy none|enforce

group-wide setting:

groupModify --group blah --piv-policy none|enforce

per-host: not really doable, because nobody has the authority over a given host, from the point of view of the bastion: a host can be in 2 distinct groups for that matter, with 2 distinct owners. Or a group can be 0.0.0.0/0 and have all the possible hosts in it.

But then, you might also want to grant an account the right to bypass the realm-wide policy, because this account might be a robot and doesn't have the required hand to click on his PIV key...

This is what has been done for password MFA and TOTP MFA:

accountModify --account joe --mfa-totp-required yes|no|bypass
accountModify --account joe --mfa-password-required yes|no|bypass

@speed47
Copy link
Collaborator

speed47 commented Nov 5, 2020

In any case @Alkorin we'll need yubico-piv-checker ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature This is a new feature request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants