2

I'm trying to figure out where does Google CHrome fetch my identity from when authenticating to an Identity Provider (SAML with certificate authentication) What I have tried :

Delete all cookies, saved passwords, cache files

Delete my personal certificate (the one i authenticate with) from my personal store)

On Firefox, this is enough to get the IDP to sign me out and prompt me for the certificate again if I refresh the page, but on Chrome, it just logs me back in !

on chrome://password-manager-internals/ , I can see the process of loading a password (I don't know which since the only password I entered was the one to decrypt my user certificate which I deleted !):

Message: PasswordAutofillAgent::DidStartProvisionalLoad
PasswordManager::DidNavigateMainFrame: false
The new state of the UI: 0
Message: PasswordAutofillAgent::SendPasswordForms
only_visible: false
Security origin: https://ADFS-IDP/
Number of all forms: 1
Message: PasswordAutofillAgent::SendPasswordForms
only_visible: true
Security origin: https://ADFS-IDP/
Number of all forms: 1
Form found on page: {
    Action : https://ADFS-IDP/ ,
    Form name or ID :
}
Form is visible: false
Some control elements not associated to a form element are visible: false
Message: PasswordManager::CreatePendingLoginManagers
Message: PasswordManager::OnPasswordFormsRendered
Message: PasswordManager::IsAutomaticSavePromptAvailable
Message: No provisional save manager
HTML form for submit: {
    Action : https://ADFS-IDP/ ,
    Form name or ID :
}

My question is : where does Chrome get my identity from that Firefox doesn't? I'm guessing Chrome has many Windows-based authentication features because the same thing happens on the Edge Browser, Any ideas please?

Gerald Schneider
  • 23,274
  • 8
  • 57
  • 89
MeMow
  • 292
  • 1
  • 7

1 Answers1

1

SAML authentication uses AD FS or another Identity Provider for SAML SSO, browser itself is never an IdP. Indeed, Chrome has capability to take the Windows session token and pass it to Service Provider (SP). SAML itself doesn't use the certificate as identity but your ADFS server may. If your ADFS is configured to multiple ways to identify the user it will do even without certificate.

Note: certificate authentication is normally used by ADFS only for external user authentication when AD is not reachable while primary identity source is still AD.

For Azure AD to have SSO implemented a special add-in is used "Windows 10 accounts". In most of the cases hybrid identity mode is used by many companies thus, Azure AD leverages user authentication to on-premises ADFS.

Note: when deleting a certificate and having already authenticated on ADFS your session token is preserved in Windows session.

If you would run Chrome in Private mode SSO would not happen as this mode doesn't have access to the Windows session context.

To investigate deeper how SAML auth in happening in Chrome I recommend to install SAML message decoder plugin. This will give you a clue of SAML Request and Response. In the request you should check saml2p:AuthnRequest and saml2:Issuer. I would look at AssertionConsumerServiceURL and Destination in the request to identify where it's coming from.

Also you need to check samlp:Response and it's Issuer. By the issuer value you will understand what IdP has responded and in the Subject session of the payload you will see how the user was identified. SAML request SAML Response

Hardoman
  • 255
  • 1
  • 7
  • Only Certificate authentication is checked for both intranet and extranet on the ADFS side, behaviour is happening even in Chrome Private mode. Where it DOES NOT happen is when I have msedge.exe on my machine instead of MicrosoftEdge.exe as a browser, i'm guessing these two work differently – MeMow Dec 29 '20 at 13:28
  • I can't repro your behavior but in any case browser itself doesn't do any authentication. They just handle session token this or that way. it is expected that different browsers handle it differently. – Hardoman Dec 29 '20 at 13:32
  • 1
    I suggest to install SAML message decoder plugin to Chrome and check what SAML token payload actually contains. This will give you a clue of saml2p:AuthnRequest and saml2:Issuer. I would look at AssertionConsumerServiceURL and Destination there to identify where it's coming from. Also you need to check samlp:Response and it's Issuer. By the issuer value you will understand what idP has responded and in the Subject session of the payload you will see how the user was identified. – Hardoman Dec 29 '20 at 13:39
  • although this is not a straight forward answer but a very helpful lead, ill mark as answer because, as you said, issue is not that common to be reproduced – MeMow Dec 29 '20 at 15:03
  • @MeMow thanks, appreciated. – Hardoman Dec 29 '20 at 15:24