Forum Discussion
Community ManagerThe new Azure AD sign-in and “Keep me signed in” experiences rolling out now!
Kelvin, correct me if I'm wrong, but most of the complaint about the auto-redirect with just filling in the UPN were because it didn't allow users to select the KSMI checkbox. Now that that's a separate step, this issue no longer applies?
On the Private session thingy, does KMSI even work with Private sessions? It writes a cookie, no? Which is *not* saved if/when I'm using a Private session. So displaying the KMSI step is pointless?
And one other thing comes to mind after seeing the comments made by other folks here - are you guys respecting the "LoginOptions" parameter for federated logins/smart links? The idea being that it automatically ticked the KMSI checkbox in the old experience...
MicrosoftYou are correct, showing KMSI in private sessions doesn't really do very much. However, there's no deterministic way for us to determine that we're in a private browser session.
Regarding LoginOptions, I believe we have discussed this before. We don't officially support the use of LoginOptions - it's an internal parameter used to pass information across our pages. We did not change how it is used with the new experiences, though we cannot guarantee that it won't happen in a future change. :)
@Kelvin, I'm not a programmer so I will trust you on the Private session thingy, although I've seen some JS samples that supposedly to just that. In all fairness, the previous experience wasn't detecting private sessions either. It's just that the KMSI is a separate step now, thus more visible, and can be a bit irritating :)
And on a related topic, can you folks please publish an official statement on what's supported in terms of smartlinks now? Just the other day you published an article mentioning 46% of all auths are AD FS, and I'm certain many of these do take advantage of smart links. Yet, there is zero documentation on them from Microsoft.
- Kelvin XiaThat's because we don't officially support them :).
We've seen multiple issues and escalations caused by customers creating links that jump straight into the middle of our flows in a way that they weren't designed for. That makes things very fragile as those customizations break when we push new features or updates.
I'll take an action to see if we can get out an official message regarding use of smartlinks.@Kelvin I see your point, but if we had proper documentation on what's supported and not and how the different flow works, I'm sure that would decrease the number of escalations :)
Smart links are still required for true, seamless SSO experience in some cases, and there is definitely demand for such from the enterprise customers. If you can publish some guidelines and recommendations, I think it will benefit all sides.
Anyway, I'll stop with the offtopic :)
