Feature Request - IWA pass through capabilities - align with .net
danield137 opened this issue · comments
I am one of the devs working on https://github.com/Azure/azure-kusto-python.
We are currently using adal for azure authentication, and we get a lot of requests for silent authentication flow (as we provide in our .net SDK).
Currently, adal python does not expose such a capability, all though it seems possible to achieve using similar low level, OS dependent code.
We would love the ability to provide silent auth for our windows users, and, to take a part of the dev effort, if needed.
@rayluo & @danield137 , as I understand, silent authentication is not available in ADAL for Python yet . So is there a way through which we can still achieve SSO using ADAL for Python?
To be precise, it is true that the Integrated Windows Auth (IWA) - i.e. current Windows login user can sign in without typing password - is not currently available in either ADAL Python and MSAL Python. You can upvote this feature request. As an open source library, we are open to PR contributions. CC: @danield137 ;-)
On a side note, the lastest version of MSAL .Net and MSAL Python are already using same format of token cache. So if you happen to have an app powered by MSAL .Net and its another version powered by MSAL Python, and they share access to same physical token cache, one app can pick up the other app's token, therefore sign in silently.
In a more generic case, though, you can consider an alternative, the Device Flow. In such flow, the actual sign-in happens on end user's another device, such as their desktop or mobile, which they typically already signed in. It is not necessarily more convenient because the end user would still need to read and type a short user code in such flow, but it is probably more secure than username-password-flow, because the end user does not need to type their password in your app (and worrying whether your app would persist their password - and you should not do that!).
If you have follow-up questions on how to use Device Flow, please create another issue for that topic. Thanks!
This feature would be awesome, how many upvotes does it need before you consider implementing it?
@jorgst Thanks for your nudge. :-) We understand that this issue is currently already the most upvoted feature request in this repo. We will defnitely get around to it. From a technical standpoint, this feature is about a platform-specific behavior (which also happens to have a less-convenient-but-still-works workaround as Device Flow). We are now inclined to prioritize some platform-independent features that are potentially covering more customers on multiple platforms. Our roadmap is available here.
any news on this?
Sorry, it looks like our roadmap page does not currently provide future plan anymore. Perhaps we should re-draft a roadmap and/or just point people to our kanban board. /CC: @navyasric
Anyway the short answer to this issue remains unchanged: while this feature is a good-to-have and also happens to have a workaround, we currently have some 2~3 other more urgent demands to satisfy. We will revisit this after that.
Is there a plan to ever implement IWA for Python?
We work in an environment where Windows sessions are automatically started, and scripts start in the context of a user thus only IWA can be of use here. Having silent/transparent authentication is required in that case.
Right now we created a .NET executable to get a valid Azure AD token and call it from Python, but that's far from ideal.
Even if you don't plan on implementing IWA, do you think of alternatives we could rely on?
Intergrated Windows Auth (IWA) is still not available in MSAL Python. There are alternatives.
-
Since Dec 2020, MSAL Python 1.7+ supports an
acquire_token_interactive(..., login_hint="johndoe@contoso.com"). Your app would need to somehow have that login hint email, either by asking end user to declare it just once, or by reusing theresult["id_token_claims"]["preferred_username"]came back from a prior successful acquire_token_by_xyz(...) call.Your end user will only be prompted for the first
acquire_token_interactive(..., login_hint="johndoe@contoso.com")call, and subsequentacquire_token_interactive(..., login_hint="johndoe@contoso.com")will silently succeed (although a browser window will still be pop up and left behind). Or if you prioritize theacquire_token_silent()as demonstrated in the same sample, your end user will be served byacquire_token_silent()most of the time.While this alternative is not strictly silent, it is still relevant, because IWA has its own constraints especially for 2FA, and falling back to Interactive auth is sometimes inevitable.
-
Placeholder. (I'll update this part in the near future.)Another option is to use the broker feature available since MSAL Python 1.20.
Both alternatives are demonstrated in the same interactive flow sample.
Thanks @rayluo your feedback is much appreciated
IWA is not a good path forward. It is better to use the new capabilities of Windows Broker to get SSO with Windows. @rayluo can point you at a sample showing how to get that.
SSO with WAM is much more stable, doesn't require complex setup and it works with Personal accounts as well.
IWA is not a good path forward. It is better to use the new capabilities of Windows Broker to get SSO with Windows. @rayluo can point you at a sample showing how to get that.
SSO with WAM is much more stable, doesn't require complex setup and it works with Personal accounts as well.
Agreed with @bgavrilMS . Updated my message above to include the 2nd option and sample. Closing this issue as wontfix.
Hello. @rayluo We have a working implementation of Integrated Windows Authentication flow with MSAL python. Do we think we can get it merged if we raise a PR?
Hi @shajia-deshaw - is there a reason why you can't use broker silent authentication instead of IWA?
@bgavrilMS Even if we go with the broker approach, I believe we still have to interactively authenticate once the first time and the subsequent token calls are silent. We would prefer to avoid that scenario as well. With IWA flow, it's silent even the first time. We would also want to avoid starting another broker process to handle authentications in our use-case right now. However if it's necessary and if MSAL will default to broker flow in the future, we will revisit the broker flow in the future. For now, integrated windows authentication is necessary for our use-case.
I believe we still have to interactively authenticate once the first time and the subsequent token calls are silent - no, the first auth is silent too. As will all silent auth, consent is still a factor - i.e. tenant admin needs to pre-consent to avoid consent issues.
@bgavrilMS Oh, that's great. We'd need to evaluate with the team about getting the pre-consent though. As I've been reading about the broker authentication, in mobile devices Microsoft Authenticator / Intune Company Portal can act as the broker, WAM in certain versions of Windows. Our service would be running in Linux boxes. The docs here (under the WAM Limitations section) says it's not supported in Linux yet. How would this work in Linux?
Broker solutions on Mac and Linux are in development. But that should not be a factor in this conversation context. You were asking about IWA, which is Windows-only anyway.
@rayluo @bgavrilMS Integrated Windows Authentication works in our Linux environment btw. We have Kerberos authentication enabled in our Linux hosts which works with our ADFS (It's a custom built solution in our infra). FYI, the IWA flow in Java worked seamlessly in our environment. We have ported that to python which also works fine.
If we're on the same page here, shall we revisit the comment in #31 (comment) to see if the IWA changes could be merged to upstream?
Reopening the issue, @ashok672 can have a look if this is in line with the current public client strategy.
@bgavrilMS Should I go ahead and raise a PR then?
Hey (@bgavrilMS / @rayluo), checking in here for an update.
@bgavrilMS Should I go ahead and raise a PR then?
I'll defer that question to @bgavrilMS and/or @ashok672 .
Meanwhile, it sounds like @shajia-deshaw already has the changes readily available in his/her fork. Then I suppose it doesn't hurt to have @shajia-deshaw share a link to that branch, so, at the very least, future readers of this thread can use that as a sample.
@rayluo Sounds good. Will do.
Hi @rayluo & @shajia-deshaw, have either of you got the link to the branch, that will be very helpful for us, appreciate your time and efforts on this.
@velulev Sorry, was caught up with some work at work :p. I'll try to spin up something in 2 weeks.
Hi @shajia-deshaw , thank you very much for getting back, any pointers or help any earlier is very much appreciated too.
Hi @shajia-deshaw, thank you very much, and really appreciate your efforts on this, from myself, and hopefully on the wider community that will benefit as well.