Assigned
Status Update
No update yet.
Comments
an...@google.com
The R8 build does include these files in our jar and they are not used/needed. I'll amend our build to avoid including them and merge it to the release branches.
jb...@orionlabs.io
Project: r8
Branch: master
commit 80533c96c4561ab997f18ce65dd2c0c6a37a33b5
Author: Ian Zerny <zerny@google.com>
Date: Thu Jan 24 10:32:09 2019
Don't include kotlin module files in distribution.
Bug: 123310328
Change-Id: Ie70d4b15f08ffc0e7b754c558079002bd6a84334
M build.gradle
https://r8-review.googlesource.com/33381
Branch: master
commit 80533c96c4561ab997f18ce65dd2c0c6a37a33b5
Author: Ian Zerny <zerny@google.com>
Date: Thu Jan 24 10:32:09 2019
Don't include kotlin module files in distribution.
Bug: 123310328
Change-Id: Ie70d4b15f08ffc0e7b754c558079002bd6a84334
M build.gradle
se...@google.com
Project: r8
Branch: d8-1.3
commit 73a2e504b0edd45eac64b6f242346b2793eae1fe
Author: Søren Gjesse <sgjesse@google.com>
Date: Fri Jan 25 09:23:25 2019
Version 1.3.54
Manually applied: Don't include kotlin module files in distribution.
CL:https://r8-review.googlesource.com/c/r8/+/33381
Bug: 123310328
Change-Id: Ifa5057f0c09d864295e200c287fb3d54cd3c79bf
M build.gradle
M src/main/java/com/android/tools/r8/Version.java
https://r8-review.googlesource.com/33485
Branch: d8-1.3
commit 73a2e504b0edd45eac64b6f242346b2793eae1fe
Author: Søren Gjesse <sgjesse@google.com>
Date: Fri Jan 25 09:23:25 2019
Version 1.3.54
Manually applied: Don't include kotlin module files in distribution.
CL:
Bug: 123310328
Change-Id: Ifa5057f0c09d864295e200c287fb3d54cd3c79bf
M build.gradle
M src/main/java/com/android/tools/r8/Version.java
jb...@orionlabs.io
Project: r8
Branch: d8-1.4
commit 2fe3fcb0dc21ed70eb37cc74aae247deffc90d29
Author: Søren Gjesse <sgjesse@google.com>
Date: Fri Jan 25 09:12:36 2019
Version 1.4.30
Cherry-pick: Don't include kotlin module files in distribution.
CL:https://r8-review.googlesource.com/c/r8/+/33381
Bug: 123310328
Change-Id: I92dce45d6c031f2dd58780b0278a188142b21523
M build.gradle
M src/main/java/com/android/tools/r8/Version.java
https://r8-review.googlesource.com/33483
Branch: d8-1.4
commit 2fe3fcb0dc21ed70eb37cc74aae247deffc90d29
Author: Søren Gjesse <sgjesse@google.com>
Date: Fri Jan 25 09:12:36 2019
Version 1.4.30
Cherry-pick: Don't include kotlin module files in distribution.
CL:
Bug: 123310328
Change-Id: I92dce45d6c031f2dd58780b0278a188142b21523
M build.gradle
M src/main/java/com/android/tools/r8/Version.java
la...@gmail.com
This change has landed in studio-3.3-dev and studio-3.4-dev. It has not yet landed in master, but will get there early next week when we do the weekly roll of R8 into studio.
se...@google.com
Fantastic!
jb...@orionlabs.io
This is not at all what this request is looking for. The desire/need is for
Google IdP to be capable of signalling, via SAML interaction with an SP, to
that SP affirming that the user, when authenticating with their Google
credentials, have completed a 2nd factor verification.
In workflow:
Hi SP, I want in -> SP responds "Google is in charge but we require 2FA"
-> User is greeted with Google auth window -> User completes Google
authentication and either validates 2FA or has a valid cookie indicating
that the user has previously completed 2FA validation -> Google sends SAML
verification to SP indicating that user authenticated successfully AND that
2FA validation has been completed -> SP accepts auth validation and 2FA
confirmation via SAML and logs user into application.
Currently this works like:
Hi SP, I want in -> SP responds "Google is in charge but we require 2FA"
-> User is greeted with Google auth window -> User completes Google
authentication and either validates 2FA or has a valid cookie indicating
that the user has previously completed 2FA validation -> Google sends SAML
verification to SP indicating that user authenticated successfully but
doesn't have a mechanism to indicate to SP that 2FA was completed or is
valid-> SP accepts auth validation and then presents user with SP's 2FA
verification flow -> User completes that 2FA process and then is granted
access to application.
The current process, assuming a valid 2FA cookie is not present for Google
authentication, requires the user to log in with U/P, then complete Google
2-step verification, then complete SP 2FA verification and is a lousy user
experience.
On Thu, Jun 9, 2022 at 6:58 AM <buganizer-system@google.com> wrote:
Google IdP to be capable of signalling, via SAML interaction with an SP, to
that SP affirming that the user, when authenticating with their Google
credentials, have completed a 2nd factor verification.
In workflow:
Hi SP, I want in -> SP responds "Google is in charge but we require 2FA"
-> User is greeted with Google auth window -> User completes Google
authentication and either validates 2FA or has a valid cookie indicating
that the user has previously completed 2FA validation -> Google sends SAML
verification to SP indicating that user authenticated successfully AND that
2FA validation has been completed -> SP accepts auth validation and 2FA
confirmation via SAML and logs user into application.
Currently this works like:
Hi SP, I want in -> SP responds "Google is in charge but we require 2FA"
-> User is greeted with Google auth window -> User completes Google
authentication and either validates 2FA or has a valid cookie indicating
that the user has previously completed 2FA validation -> Google sends SAML
verification to SP indicating that user authenticated successfully but
doesn't have a mechanism to indicate to SP that 2FA was completed or is
valid-> SP accepts auth validation and then presents user with SP's 2FA
verification flow -> User completes that 2FA process and then is granted
access to application.
The current process, assuming a valid 2FA cookie is not present for Google
authentication, requires the user to log in with U/P, then complete Google
2-step verification, then complete SP 2FA verification and is a lousy user
experience.
On Thu, Jun 9, 2022 at 6:58 AM <buganizer-system@google.com> wrote:
--
Jason Bradford -- (he, him)
Director of Information Technology & Security at Orion
​​​​(415) 800-2035 ext.754​ | jbradford@orionlabs.io
se...@google.com
Hello,
Apologies for the delay.
This is being consulted, I will let you know any updates as soon as possible.
Regards.
lo...@google.com
Hello,
This has been reported internally.
Any updates will be posted here.
Have a nice day!
jb...@orionlabs.io
is...@google.com
jp...@google.com
be...@doctrine.fr
Hello,
We are facing the same issue.
This lack of support for MultipleAuthN forces us to maintain double 2MFA authentication on Microsoft Office 365.
Is there any update ?
Thanks !
We are facing the same issue.
This lack of support for MultipleAuthN forces us to maintain double 2MFA authentication on Microsoft Office 365.
Is there any update ?
Thanks !
fr...@bluegriot.com
Hello,
We're experiencing the same issue: without multipleAuthn support, our users are forced to complete MFA twice (Google + Office 365).
Is there any update or workaround to avoid this double prompt?
Thanks!
We're experiencing the same issue: without multipleAuthn support, our users are forced to complete MFA twice (Google + Office 365).
Is there any update or workaround to avoid this double prompt?
Thanks!
br...@gmail.com
We're seeing this as well. When logging into the MS/Azure portal with Google Workspace as the IdP, the lack of this "multipleAuthn" SAML assertion means that MS doesn't have a way to know the user already performed MFA, so it forces another MFA method on the MS side.
Impact: We have to have 8hr sessions on the Google side, so basically this entire dance is forced on us and all our users 1-2x per day per device. This isn't just limited to Azure/MS, too.
Impact: We have to have 8hr sessions on the Google side, so basically this entire dance is forced on us and all our users 1-2x per day per device. This isn't just limited to Azure/MS, too.
ic...@babotaniek.be
+1
please implement this
please implement this
Description
More specifically, we can use Google identities to authenticate to M365 accounts via SAML configuration with no AD infrastructure or ADFS necessary. This is great but when it comes to signing into Windows systems with a Microsoft account that is SAML federated to Google identities, so long as web sign-in is enabled on the system, this works great...BUT that login requires Google Username and password followed by Google 2Step authentication followed by Microsoft Authenticator secondary authentication. Adding this feature would enable good UX for this type of login flow and remove the need for MS Authenticator.
Disabling MFA requirements on MS365/AzureAD is not a great option but when it is set, it does not remove the MFA requirement for system login so that is not a viable workaround.
GCPW is fairly slick but only supports local account creation and thus is not viable for using MS accounts which are necessary for proper management of our Windows environments.