LG-12143 Create a vector of trust parser #9971
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
zachmargolis
approved these changes
Jan 24, 2024
matthinz
approved these changes
Jan 24, 2024
jmhooper
force-pushed
the
jmhooper-vot-parser-3
branch
from
1116b9c
to
b19b296
Compare
aduth
approved these changes
Jan 25, 2024
This commit introduces a service that can take a string representing a vector of trust and parse it into its components and values. Vectors of trust are described in RFC 8485. We are planning to use vectors of trust in our OIDC interface to allow service providers to describe the authentication and identity proofing feature set they need in place for their use case. This will be an alternative to ACR values. To that end this commit includes VoT 2 components with their own unique values. Together these form 6 valid pairs of components and values. The `P` component represents identity proofing. It contains the following values: - `1`: Identity proofing is performed - `2`: A biometric comparison is performed as part of identity proofing (this is a future offering) The `C` component represents credential usage. This essentially describes authentication features. It contains the following values: - `1`: Password authentication + MFA - Implied for all transactions - `2`: AL2 conformant features engaged (e.g. no remember device) - `a`: A phishing resistant authenticator is required - `b`: A PIV or CAC is required The construction of this mapping satisfies LG-12151. As an example for how this new tool behaves, consider the vector "C2.P1". The "P1" vector implies the "C2" vector which is already included. The "C2" vector implies the "C1" vector. This results in the vector being expanded into "C1.C2.P1". The result that is returned form the parser includes fields for the requirements for the authentication and identity proofing transaction. It includes the following requirements: - `aal2`: AAL2 is required - `phishing_resistant`: Phishing resistant authenticators are required - `hspd12`: PIV/CAC is required - `identity_proofing`: Identity proofing is required - `biometric_comparison`: A biometric comparison is required This allows the result to be used to describe an authentication context that can be used to construct policies that ensure the requirements for the vector of trust are met. [skip changelog]
jmhooper
force-pushed
the
jmhooper-vot-parser-3
branch
from
8120d79
to
04cac6c
Compare
| private | ||
|
|
||
| def vot_parser_result | ||
| vector_of_trust = JSON.parse(vtr).first if vtr.present? |
There was a problem hiding this comment.
I am surprised by the JSON.parse, I'd expect an outside class to handle that? But we can also transition that easily in a future PR
There was a problem hiding this comment.
I moved it here in case we eventually want to support ["C1.P1", "C1"] in order to support ialmax for VTR users.
There was a problem hiding this comment.
I would have this take in an array of strings then? And always call Array(value) on the input
There was a problem hiding this comment.
I think it needs to be an array either way (or array of arrays initially even)?
There was a problem hiding this comment.
Okay, I just pushed a change:
- ACR values is still a string. This is necessary to parse them with the
VotParser. - VTR is an array. I am assuming here that upstream (perhaps in the OIDC form and in the SAML Request) we will parse the JSON into an array. This has the added benefit of allowing us to accept values that are not JSON even if that deviates from the spec.
jmhooper
added a commit
that referenced
this pull request
Jan 29, 2024
* Add the requested vectors of trust to `ServiceProviderRequest` We are working on implementing a feature for partners to request identity proofing and authentication features using vectors of trust. This will involve sending param describing the vector of trust in the original SAML or OIDC request. Within the context of OIDC this param is named `vtr`. This commit adds a `vtr` property to `ServiceProviderRequest`. This property is unused and unset in the persisted service provider request. This will allow us to write to it in the future and initialize `ServiceProviderRequest`s with the value without resulting in an `ArgumentError` (thus avoiding a dreaded 50/50 state bug) This commit also adds an `acr_values` property. This is looking forward to when parameters are consumed by the parser introduced in #9971. [skip changelog]
zachmargolis
approved these changes
Jan 29, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit introduces a service that can take a string representing a vector of trust and parse it into its components and values.
Vectors of trust are described in RFC 8485.
We are planning to use vectors of trust in our OIDC interface to allow service providers to describe the authentication and identity proofing feature set they need in place for their use case. This will be an alternative to ACR values. To that end this commit includes VoT 2 components with their own unique values. Together these form 6 valid pairs of components and values.
The
Pcomponent represents identity proofing. It contains the following values:1: Identity proofing is performed2: A biometric comparison is performed as part of identity proofing (this is a future offering)The
Ccomponent represents credential usage. This essentially describes authentication features. It contains the following values:1: Password authentication + MFA - Implied for all transactions2: AL2 conformant features engaged (e.g. no remember device)a: A phishing resistant authenticator is requiredb: A PIV or CAC is requiredThe construction of this mapping satisfies LG-12151.
As an example for how this new tool behaves, consider the vector "C2.P1". The "P1" vector implies the "C2" vector which is already included. The "C2" vector implies the "C1" vector. This results in the vector being expanded into "C1.C2.P1".
The result that is returned form the parser includes fields for the requirements for the authentication and identity proofing transaction. It includes the following requirements:
aal2: AAL2 is requiredphishing_resistant: Phishing resistant authenticators are requiredhspd12: PIV/CAC is requiredidentity_proofing: Identity proofing is requiredbiometric_comparison: A biometric comparison is requiredThis allows the result to be used to describe an authentication context that can be used to construct policies that ensure the requirements for the vector of trust are met.