W3C home > Mailing lists > Public > public-webauthn@w3.org > March 2020

Re: [webauthn] Consider allowing cross-domain credential use (#1372)

From: eirbjo via GitHub <sysbot+gh@w3.org>
Date: Fri, 06 Mar 2020 09:50:06 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-595689724-1583488205-sysbot+gh@w3.org>
Here’s a use case we stumbled upon just yesterday:

Microsoft recently announced support for FIDO authentication in Azure Active Directory hybrid environments [1]

When a user registers a FIDO credential with Microsoft Azure, their FIDO credential is made available as an attribute (msDS-KeyCredentialLink) on the user’s Active Directory account.

For the FIDO case, this attribute contains the authdata (with credential ID) and an x509 representation of the FIDO public key. [2] 

Since our product already integrates with Active Directory, we have read access to this “msDS-KeyCredentialLink”, thus we have the credentialId needed to issue a get_credential, and we have the public key we need to validate the assertion.

The only thing stopping us from reusing the user’s Azure FIDO credentials is a missing cross-origin mechanism exactly as discussed in this issue. 

For an RP implementor like us, it’s seems really appealing to allow the user to reuse already registered Azure credentials instead of having to re-register the same authenticator in each and every  application supporting FIDO across their enterprise. (Our product is an extension which alone can be installed in five different host products)

I understand that this could be solvable using iframe with some form of sso or federation. But that would mean special-casing the user interface for dealing with iframes and whatever is shown in the iframe would be out of our control as an RP implementor. 

I sympathise with anyone worried about added complexity to the architecture. However, my sympathy is always greater with the end user. She wants it to “just work”, and I think a solution as discussed in this thread would be a great help in that regard.

One additional input: Any cross-origin solution here should be tenant-aware. In concrete terms, an Azure global administrator should be able to register relying parties for cross-origin in their tenant, without involving Microsoft. (The alternative being that Azure had one global list of allowed relying parties, which would not scale and be a security and organisational nightmare..)

That’s my 2 cents, happy to clarify this use case if anyone’s curious.

Cheers,
Eirik.  


[1] https://techcommunity.microsoft.com/t5/azure-active-directory-identity/public-preview-of-azure-ad-support-for-fido2-security-keys-in/ba-p/1187929
[2] https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/d5948ab9-8993-4066-a175-851af361ea7f

-- 
GitHub Notification of comment by eirbjo
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1372#issuecomment-595689724 using your GitHub account
Received on Friday, 6 March 2020 09:50:08 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 07:26:40 UTC