-
Notifications
You must be signed in to change notification settings - Fork 330
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
manged or federated - x-client-SKU header makes a difference #1860
Comments
Just to add, I asked this question as this may relate to an issue we saw a while ago - I cannot reproduce it anymore but can quickly describe it here:
I cannot re produce this issue anymore because after a while 1) just magically worked. But do wonder if it was the different value of x-client-SKU (msal vs ssms) makes a difference from my observation today. Thanks. |
You are right, the server has different behaviour based on x-client-SKU and x-client-Ver :(. This was done so as not to break backwards compatibility with non-MSAL libraries or apps calling the server on their own. I believe the version needs to be at least 4 for this client-SKU for "seamless SSO" to work. We do not document these feature flags, as these are implementation details. We do not expect developers to replicate IWA calls, as it is quite complex, so "seamless SSO" is only supported via MSAL libraries. Do you have a scenario where you cannot a MSAL library? |
Thanks for your reply all makes sense, is it correct to think if the AAD is configured with ADFS then it's always federated with/without headers, x-client-SKU and x-client-Ver are only significant in the AAD where SSO is enabled because this is only supported since version 4? "Do you have a scenario where you cannot a MSAL library?" If you could shed light on this it's great, or if it's purely environment issue then I'm happy to close this question based on your last answer. Thanks a lot. |
Yes, Integrated Windows Auth is a pretty complex flow which the team copied from ADAL. But since most of us were new to the team, we did not have enough context into Seamless SSO and we did not test this scenario originally. After customers complained that seamless SSO was not working with MSAL, we realized that a feature flag needed to be set on the server (i.e. AAD knows to return "managed" if x-client-ver is >4 and x-client-sku is MSAL.NET). That's why you saw the issue resolve itself. We are looking at using a more robust mechanism for feature flagging in the future, as this is often a problem, especially when new MSAL libraries are created (e.g. java, python) |
Thanks a lot! |
hello guys,
This is a question related to IWA flow - I am trying to understand the protocol a bit more:
I understand as part of the IWA protocol it will make a userealm request and to check if user account is managed or federated in the response. I've come across some really weird behavior:
the two requests (for the same user) returns different result depends on x-client-SKU headers are included or not:
let testuser1@mydomain.co.uk as an example (I've replaced the real domain)
GET https://login.microsoftonline.com/common/userrealm/testuser1@mydomain.co.uk?api-version=1.0 HTTP/1.1
Host: login.microsoftonline.com
Accept: application/json
x-client-SKU: MSAL.Desktop
x-client-Ver: 4.13.0.0
x-client-CPU: x64
x-client-OS: Microsoft Windows NT 6.2.9200.0
This returns a response and with account_type = federated.
GET https://login.microsoftonline.com/common/userrealm/testuser1@mydomain.co.uk?api-version=1.0 HTTP/1.1
Host: login.microsoftonline.com
Accept: application/json
This request returns a response with account_type = Managed
the only difference is presence/unpresence of x-client-SKU headers, is this behavior documented somewhere please?
I fully understand this is not a MSAL issue, but just curious how these headers become significant.
since @bgavrilMS pasted the same user discovery url in the other post which can be opened via browser (i.e. headers not presented) so I'm under the impression that you guys would expect behavior to be the same?
If this is the wrong place to ask could you please point me to the right place.
Thanks a lot.
![s1](https://user-images.githubusercontent.com/42645223/83628081-dcb55880-a58f-11ea-8192-c460fc6799b0.jpg)
![s2](https://user-images.githubusercontent.com/42645223/83628082-dd4def00-a58f-11ea-9aa5-41c80ddbbb21.jpg)
The text was updated successfully, but these errors were encountered: