Skip to content
This repository was archived by the owner on Jun 17, 2022. It is now read-only.

Conversation

@eliykat
Copy link
Member

@eliykat eliykat commented Dec 9, 2021

Type of change

  • Bug fix
  • New feature development
  • Tech debt (refactoring, code cleanup, dependency upgrades, etc)
  • Build/deploy pipeline (DevOps)
  • Other

Objective

See bitwarden/web#1332.

Code changes

Directives:

  • angular/src/directives/a11y-invalid.directive.ts: automatically apply the aria-invalid attribute depending on the state of the linked formControl. (Used on all controls to make them accessible.)
  • angular/src/directives/input-strip-spaces.directive.ts: automatically strip spaces from certain inputs (used on URL fields)

Validators:

  • angular/src/validators/dirty.validator.ts: design requirements were to validate on blur, but only once the user has actually changed the field value. This is achieved by setting the form to updateOn: 'blur' and then running any required validator through this factory, which only runs the validator if the field is dirty.
  • angular/src/validators/requiredIf.validator.ts: used for conditional validation, usually depending on another field.

Enums:

  • common/src/enums/ssoEnums.ts: extract the SsoApi enums into their own class and export them so we can use them in the component. Add None as an option to SsoType.

Models:

  • common/src/models/view/ssoConfigView.ts: this is a new view model because the form structure no longer reflected the api model in 2 main ways:
    • nesting SAML and OpenId options in their own FormGroups
    • inverting the value of idpDisableOutboundLogoutRequests. Design wanted it to read "allow" rather than "deny". Using separate models lets us make this change without having to change the logic all the way up into the server.
  • common/src/models/api/ssoConfigApi.ts: add helper method to create a new api model from a view model

Before you submit

  • I have checked for linting errors (npm run lint) (required)
  • I have added unit tests where it makes sense to do so (encouraged but not required)
  • This change requires a documentation update (notify the documentation team)
  • This change has particular deployment requirements (notify the DevOps team)

@eliykat eliykat changed the title Fix/sso validation Improve SSO Config validation Dec 9, 2021
Comment on lines +19 to +52
if (api.configType === SsoType.OpenIdConnect) {
api.authority = view.openId.authority;
api.clientId = view.openId.clientId;
api.clientSecret = view.openId.clientSecret;
api.metadataAddress = view.openId.metadataAddress;
api.redirectBehavior = view.openId.redirectBehavior;
api.getClaimsFromUserInfoEndpoint = view.openId.getClaimsFromUserInfoEndpoint;
api.additionalScopes = view.openId.additionalScopes;
api.additionalUserIdClaimTypes = view.openId.additionalUserIdClaimTypes;
api.additionalEmailClaimTypes = view.openId.additionalEmailClaimTypes;
api.additionalNameClaimTypes = view.openId.additionalNameClaimTypes;
api.acrValues = view.openId.acrValues;
api.expectedReturnAcrValue = view.openId.expectedReturnAcrValue;
} else if (api.configType === SsoType.Saml2) {
api.spNameIdFormat = view.saml.spNameIdFormat;
api.spOutboundSigningAlgorithm = view.saml.spOutboundSigningAlgorithm;
api.spSigningBehavior = view.saml.spSigningBehavior;
api.spMinIncomingSigningAlgorithm = view.saml.spMinIncomingSigningAlgorithm;
api.spWantAssertionsSigned = view.saml.spWantAssertionsSigned;
api.spValidateCertificates = view.saml.spValidateCertificates;

api.idpEntityId = view.saml.idpEntityId;
api.idpBindingType = view.saml.idpBindingType;
api.idpSingleSignOnServiceUrl = view.saml.idpSingleSignOnServiceUrl;
api.idpSingleLogoutServiceUrl = view.saml.idpSingleLogoutServiceUrl;
api.idpArtifactResolutionServiceUrl = view.saml.idpArtifactResolutionServiceUrl;
api.idpX509PublicCert = view.saml.idpX509PublicCert;
api.idpOutboundSigningAlgorithm = view.saml.idpOutboundSigningAlgorithm;
api.idpAllowUnsolicitedAuthnResponse = view.saml.idpAllowUnsolicitedAuthnResponse;
api.idpWantAuthnRequestsSigned = view.saml.idpWantAuthnRequestsSigned;

// Value is inverted in the api model (disable instead of allow)
api.idpDisableOutboundLogoutRequests = !view.saml.idpAllowOutboundLogoutRequests;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would this work? We send defaults from the server which we should receive on the client to show the correct defaults.

Copy link
Member Author

@eliykat eliykat Jan 12, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm I didn't realise that. I've provided the defaults client-side in the related web PR (see here). To me it makes more sense to do this client-side, because they are form defaults and the form belongs to the client. I also think it's required for the new design of the form (now that it only saves the selected configuration). I didn't notice any unexpected behaviour during my testing.

Note that the read-only fields (callbackPath, entityId, metadataUrl, etc) are still populated from the data provided by the server (for both configurations), they're outside the ssoConfig object.

What do you think?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although if we do that then I guess we should remove the defaults server-side and make sure that won't affect anything else.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine with that. Can you open a PR on the server with the removal of the defaults?

Copy link
Member Author

@eliykat eliykat Feb 22, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Hinton I came back to this and have done the following:

  • server PR as discussed above: Improve SSO Config validation server#1879
  • refactored the web PR to use reusable components rather than copy/pasting throughout the template, should now be much easier to review, and can be lifted into the component library once we have it.

@eliykat eliykat requested a review from Hinton February 22, 2022 04:00
Copy link
Member

@Hinton Hinton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks overall good, a few minor things. I think the validators could use a tiny bit of description to avoid confusion down the line.

@eliykat eliykat requested a review from Hinton February 22, 2022 21:52
@Hinton
Copy link
Member

Hinton commented Mar 1, 2022

We should be good code wise on this. Haven't tested the functionality.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants