[#734] Update meet Policy 1.1 to allow users without a Google account to join meetings

[snarve]

🗣 Description

Closes #734

Update Meet policy 1.1 so users without a Google account can join the meetings

💭 Motivation and context

The current policy Meet 1.1 restricted users to join the meeting using a Google account only. With this limitation users would need to utilize their google account to join the meetings. There is also a possibility that in the absence of an official Google account, users could use their personal Google accounts to join the meeting. Hence, this policy removes this limitation and there will be a new policy added that will allow organizers to limit who can join the meeting. #820

🧪 Testing

1. Ensure Meet policy 1.1 shows the results as expected in the report
2. The current setting for the policy is set to 'All Users', and any other setting should throw a warning in the report
3. Ensure all the unit tests pass as well

✅ Pre-approval checklist

• [x] This PR has an informative and human-readable title.
• [x] Changes are limited to a single goal - eschew scope creep!
• [x] If applicable, All future TODOs are captured in issues, which are referenced in the PR description.
• [x] The relevant issues PR resolves are linked preferably via closing keywords.
• [x] All relevant type-of-change labels have been added.
• [x] I have read and agree to the CONTRIBUTING.md document.
• [x] These code changes follow cisagov code standards.
• [x] All relevant repo and/or project documentation has been updated to reflect the changes in this PR.
• [x] Tests have been added and/or modified to cover the changes in this PR.
• [ ] All new and existing tests pass.

✅ Pre-merge Checklist

• [x] This PR has been smoke tested to ensure main is in a functional state when this PR is merged.
• [ ] Squash all commits into one PR level commit using the Squash and merge button.

✅ Post-merge Checklist

• [x] Delete the branch to clean up.
• [x] Close issues resolved by this PR if the closing keywords did not activate.

[snarve]

Currently failing 2 unit tests: data.meet.test_MeetAPI_UserJoin_Incorrect_1 and data.meet.test_MeetAPI_UserJoin_Incorrect_2. Could you please fix those unit tests?

Also general question for my understanding, if an org is more restrictive and instead of all, has it set to same organization only, should they be failing the policy?

Will address the unit tests issue, Thanks for reviewing the PR.

Yes, if it set to a more restrictive policy then it will throw a warning. But that is making me think, do we even need this policy then, since we are removing the restrictions, how is this then adding to security compliance. The new policy we will add allows the restriction at the organizer level and is independent of this policy. Let's discuss this as a parking lot item in tomorrow's meeting. Unless I missing some use cases that this policy addresses.

[dagarwal-ecs]

Currently failing 2 unit tests: data.meet.test_MeetAPI_UserJoin_Incorrect_1 and data.meet.test_MeetAPI_UserJoin_Incorrect_2. Could you please fix those unit tests? Also general question for my understanding, if an org is more restrictive and instead of all, has it set to same organization only, should they be failing the policy?

Will address the unit tests issue, Thanks for reviewing the PR.

Yes, if it set to a more restrictive policy then it will throw a warning. But that is making me think, do we even need this policy then, since we are removing the restrictions, how is this then adding to security compliance. The new policy we will add allows the restriction at the organizer level and is independent of this policy. Let's discuss this as a parking lot item in tomorrow's meeting. Unless I missing some use cases that this policy addresses.

Yes, I was trying to determine the need for the policy if it isn't restrictive at all nor does it add any security compliance? I agree we should have a parking lot about this.

[adhilto]

Currently failing 2 unit tests: data.meet.test_MeetAPI_UserJoin_Incorrect_1 and data.meet.test_MeetAPI_UserJoin_Incorrect_2. Could you please fix those unit tests? Also general question for my understanding, if an org is more restrictive and instead of all, has it set to same organization only, should they be failing the policy?

Will address the unit tests issue, Thanks for reviewing the PR. Yes, if it set to a more restrictive policy then it will throw a warning. But that is making me think, do we even need this policy then, since we are removing the restrictions, how is this then adding to security compliance. The new policy we will add allows the restriction at the organizer level and is independent of this policy. Let's discuss this as a parking lot item in tomorrow's meeting. Unless I missing some use cases that this policy addresses.

Yes, I was trying to determine the need for the policy if it isn't restrictive at all nor does it add any security compliance? I agree we should have a parking lot about this.

Discussing this as a group is a good idea, but here's my take:

1. Yes, in general, we do allow more restrictive, but there are exceptions to this rule (at least one that I know of).
2. MS.TEAMS.1.4v1 is a policy where we specifically recommend the less restrictive option: "Internal users SHOULD be admitted automatically." The reason being the more restrictive option, requiring internal users to be manually admitted, would likely lead to fatigue, possibly even weakening the overall security posture.
3. Arguably, this could be another case where an exception to the norm of allowing more restrictive is merited; because the cost of the restrictive setting here is so high (completely non-compatible for M365-based orgs), the restrictive setting will likely to just lead to insecure practices (i.e., using personal Google accounts).'

EDIT: it is worth noting though that setting this to "same org only" would prevent the personal Google accounts concern. It would make collaboration very difficult, but that's not a security concern per se.

[snarve]

@dagarwal-ecs @adhilto I was thinking of discarding this PR and closing the issue, since now that existing policy 1.1 needs to be removed, this PR will cover the removal of the policy, rego and unit tests only to add it back as a new Meet policy 1.1 (covered in issue #820 )

This requires temporarily renumbering all the follow on policies (Policy 2 on wards and renumbering them back again in #820)

Your thoughts on closing this PR and the issue.

[snarve]

I am already in the process of adding the new Meet policy 1.1 for access type.

[adhilto]

@dagarwal-ecs @adhilto I was thinking of discarding this PR and closing the issue, since now that existing policy 1.1 needs to be removed, this PR will cover the removal of the policy, rego and unit tests only to add it back as a new Meet policy 1.1 (covered in issue #820 )

This requires temporarily renumbering all the follow on policies (Policy 2 on wards and renumbering them back again in #820)

Your thoughts on closing this PR and the issue.

You can close this PR since that makes things more straightforward. But I wouldn't close #734 until the policy has actually been removed so we don't lose track of it.

[snarve]

Closing this PR, issue will close with #820