Can you try gathering logs from a device after a failed so login attempt? Just use guest mode or another account to gather the logs but do let us know the approximate time and so user of the attempt.

https://support.google.com/chrome/a/answer/3293821?hl=en

Yes, logs would be useful, but in general the login will complete once you've navigated back to Google with your SAML assertion.

I presume that you can sign in to your Google Account from a regular browser window (i.e. if you go to accounts.google.com in a guest session and sign in to the same account)?

Hello, sorry for taking longer to response, i had to setup the application
again.

@jayh: Ok, the log file is attached. (the time was near 4:13 pm on my
region)
The file that contains the log seems to be inside of the chrome folder,
filename is chrome_20171017-130230

@atwil: I am able to sign in from a regular browser.

Let me provide more informations:
There is a short video of 9s showing the behavior
https://youtu.be/Q0SqQWoGlto

The steps are:
- google.principal.initialize
- on the callback of initialize, i am calling google.principal.add
- on the callback of add, i am calling the google.principal.complete
- on the callback of the complete, i am authenticating in our application
- on the callback of our authentication, i am initializing the SSO flow
- after the flow is finished, the form do not close

Jay, did you get the log file?

It doesn't look like the SAML flow is redirecting back to Google at the end. You still need to follow the full SAML flow, including redirecting back to the URL specified in the SAML request at the end - that's how we know the user has completed the flow. You can't just use XHR to communicate your SSO behind the scenes, if that's what you're doing.

To put it another way:
Please note that the article you followed (Advanced Integration for SAML SSO on Chrome Devices[1]) is describing an additional API IdPs can implement in order to pass the password to Chrome OS in a good way (which Chrome OS uses to encrypt the user's home directory with). It is not describing the actual SAML flow details.

It may be that your IdP is missing Step 5/6 from page 29 of this document:
https://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf

The redirect is also mentioned in [1] under:
complete(details, callback)
[..] After verifying the user’s credentials, an IdP needs to redirect to a Google URL, passing the RelayState and SAMLResponse. This is typically done by serving an HTML page that contains a hidden form which is submitted to the Google URL automatically upon page load. [..]

Are you sure that this redirect is happening?

BTW, I haven't seen the attached logs - are you sure you've attached them?

[1] http://www.chromium.org/administrators/advanced-integration-for-saml-sso-on-chrome-devices

OK, i am reading the document and checking the flow again.
The log file is attached here.

Deleted: debug-logs_20171017-131434.tgz 1.8 MB

debug-logs_20171017-131434.tgz 1.8 MB Download

Some additional details about our flow:

- Once the callback of the google.principal.complete is executed, we are submiting the form to initiate SSO. It is calling the controller which uses a SAML library from Component Space for ASP.NET.
The method signature is this:
void InitiateSSO(HttpResponseBase httpResponse, string userName, IDictionary<string, string> attributes, string relayState, string partnerSP, string assertionConsumerServiceUrl);

- After initiate, the flow goes to Google and returns to our application, it is hitting our another ActionResult SSOService(), which send a the response assertion to the service provider using the following method:
void SAMLIdentityProvider.SendSSO(Response, szPartnerUserName, userAttributes);

I have two questions to know if i am in the right way:
- It is correct to submit the form just when the google.principal.complete is executed?
- What is the action that unlock the device? A call from SP (google.com) to our page?

The current flow is similar to the 'IdP-Initiated SSO: POST Binding' in the page 34 of the documentation at
https://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf

Jay, David - can you follow up on this? If Support decides this is a bug and not a misconfig, then the next step would be to get test account credentials.

Hi!
The logs had any important information?
Any suggestion to help me on this?

I don't see anything obvious in the logs. Is it possible for you to share test credentials (confidentially) with us so we can see the SAML flow ourselves?

Sure, let me setup one account.
Can be for you Jayhlee?

That's fine, feel free to email me direct.

Probably an aside, but still something to keep in mind. As the documentation says:

"complete(details, callback)
The complete method should be invoked when the user’s credentials have been verified by the SAML IdP and the user is authenticated."

It is wrong to call complete() before verifying the credentials. You should do it only after the callback from your IdP comes, confirming that the credentials were correct.

@jayhlee Credentials provided... Let me know if you need anything else.
@bartfab Yes bart, i've tried both ways, the code was updated as you mentioned but the behavior is the same.

Thanks for fixing that. I found a further note in the documentation that clearly states, "If the credentials provided are incorrect, the IdP must not call the complete method." I should have known that - I implemented this feature and wrote the documentation :).

Hello!
How are you? Do you have any news about it?

@jayhlee Do you received the credentials to test the application?

Thanks for looking into this, we're getting calls from customers that want to implement this functionality.  We've found that the latest release of iOS supports this functionality with no issues which I was surprised with.  The last thing I was expecting was apple to have this working with no issues before we could get chromeOS to do the same.  

Do we have any updates on this issue?

Is this a Service Provider initiated flow you are testing with? To my knowledge, Chrome OS, and the advanced integration flow API you are testing do not support IDP-initiated flows, you need to do SP-initiated.

It sounds like you're not supporting a SAML Service Provider initiated flow which is what Chrome OS expects. You need to read the SAMLRequest from Google, handle user authentication and then send back the SAMLResponse posted to Google after successful user login.

Marking this as WAI for now but can continue to discuss further.