Skip to content

Implement step-up with WebAuthn and Roaming profiles - #566

Open
bheesham wants to merge 1 commit into
mozilla-iam:masterfrom
bheesham:add-step-up
Open

bheesham wants to merge 1 commit into
mozilla-iam:masterfrom
bheesham:add-step-up

Conversation

@bheesham

Copy link
Copy Markdown
Contributor

Jira: IAM-1989

Implemented as described in this doc.

Comment thread tf/actions.tf
value = local.parsed_secrets["duoSecurity_duo_skey"]
}

secrets {

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Duo apps have been created for dev, and the secrets have been updated.

@bheesham
bheesham force-pushed the add-step-up branch 2 times, most recently from a667b27 to 7577edf Compare September 25, 2026 20:34
expect(api.multifactor.enable).not.toHaveBeenCalled();
});

test("Matching user on non-LDAP connection; no Duo, access granted", async () => {

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I did ask AI to generate some tests, but I'm not too happy with the way it wrote this one. I'll figure out a better comment.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Yeah I'm not following how this is inspecting non-LDAP so I don't grok.

Comment thread tf/tests/accessRules.test.js Outdated
_event.client.client_id = "client00000000000000000000000011";
_event.user.email = "joe@mozilla.com";
_event.user.groups = [];
_event.user.multifactor = ["duo"];

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Also, "no Duo", but includes Duo?

@gcoxmoz gcoxmoz left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Conceptually okay but I think "boop the tests" maybe.
I will go ahead and approve because I trust you'll swizzle the few bits that are weird but I think it's safe enough.

Comment thread tf/actions/accessRules.js
groups
);
const matches = userMatches || groupMatches;
return matches ? step_up.required_indicator : undefined;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Does anything lint that step_up objects are required to have a required_indicator?
If so, great. If not, I suggest (pseudocode), if (step_up.required_indicator ?? false) { raise attributeerror }

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Yeah, that code is in sso-dashboard-configuration.

We aren't allowed to publish (er, well, I guess we can if we force merge) an apps.yml that would break this.

The comment above says as much:

    // These values are somewhat trusted, because we have tests in
    // sso-dashboard-configuration.

expect(api.multifactor.enable).not.toHaveBeenCalled();
});

test("Matching user on non-LDAP connection; no Duo, access granted", async () => {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Yeah I'm not following how this is inspecting non-LDAP so I don't grok.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants