Bring production up to date with master #286
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
…m/cis/blob/master/docs/rfcs/AutomaticAccessExpiration.md Note that the users MUST have an authoritativeGroups entry for the clientid (uuid) for the access to be updated (authoritativeGroups.lastUsed) and granted/denied. This means code in the Auth0 publisher needs to be added to detect when the value is setup and add the attribute to the corresponding users ; or ; default setup `lastUsed` on the first login attempt (which has the vulnerability of being able to "never login" then 10000 days later still be able to login for the first time. This is less of an issue for RPs that would always have had this setup of course. Note also that this is fully independent from access groups and any other access, and overrides every other access when setup. See also: mozilla-iam/sso-dashboard-configuration#148
This involves some refactoring. Note that this also means: - accessing *any* RP will update your authoritativeGroups.lastUsed timestamp for that RP - only RPs with an expiration setting in apps.yml will enforce the access expiration at this time. We may enable it by default everywhere in the future. - if you are granted access to an RP, but never use the access, your timestamp in lastUsed is never set. This means you can keep that access and it will NOT expire until you first login to the RP, and after the lastUsed attribute expires. This is a known issue that we're accepting as expiration of access is yet another additional level of security, not the primary decision for access. We may be able to fix the issue eventually, if groups get tied to roles, which themselves must be tied to an RP-subject for example (so that we know why RPs you have access to, and thus set your lastUsed timestamp as soon as you get access, regardless of you logging in or not)
Support for expiration of access
clarify examples and settings
but this solves the primary account method for mozilians.org until we come up with a good primary login method selection UX
force Fxa to be higher security than github. it may or may not be true, but this solves the primary account method for mozilians.org until we come up with a good primary login method selection UX
caching reasons (it may be longer to update)
2fa work-around for a not-so-corner case
…nstead of the AAL state (comes from id_token only)
check the fxa 2fa param (comes from user info endpoint or id_token) i…
upstream manual fixes..
Fix nodejs8 support for fetch user script jsonwebtoken no longer returns a string
last-resort maintenance page for login
change slack channel
It uses https://github.com/mozilla-iam/cis/blob/profilev2/docs/.well-known/mozilla-iam.json and stores 2 new configuration variables (the public key to verify and the well-known endpoint URL)
This comment should have changed when 0e6cf7d was made.
This is to facilitate testing Common Voice using passwordless and LDAP without ratcheting
Tested out webtask cacheing and confirmed that it does work
Update rule comments
Support wildcards in AWS-Federated-AMR role picker
This was deployed but removed from the repo
Re-introduce Everyone-is-in-the-everyone-group.js This was deployed but removed from the repo
disabling rule for now
# Conflicts: # README.md # manual/social-fxa.js # pages/login.html # rules/AccessRules.json # rules/Everyone-is-in-the-everyone-group.json # rules/Force-MFA-setup-for-GitHub-logins.json # rules/Force-MFA-setup-for-social-logins.json # rules/SAML-gcp-gsuite.json # rules/SAML-test-mozilla-com-google.json # rules/SAML-thinksmart.json # rules/force-users-login-most-secure-method.js # rules/temporary-LDAP-re-reintegration.json # rules/temporary-cis-api-integration.json # rules/temporary-hrdata.js # rules/temporary-hrdata.json
gdestuynder
approved these changes
Sep 13, 2019
update access group
Move groupIntersection inside WHITELIST block
gdestuynder
approved these changes
Sep 16, 2019
Add some details to the README about CI
These two rules don't exist in the master branch nor in the live dev or production environments Force-MFA-setup-for-GitHub-logins.js temporary-cis-api-integration.js
…on because it was reverted out of production in #227
gdestuynder
approved these changes
Sep 17, 2019
|
This was deployed live at 7:35am PDT |
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 will bring the production branch up to date with what's live in production. It will also apply two changes that are live in dev, and present in master but not yet live in production.
temporary-LDAP-re-reintegrationin Update rule comments #280AWS-Federated-AMRform Add support for new S3 hosted group role map file #279 and Support wildcards in AWS-Federated-AMR role picker #281