LastPass: SSO support

[detunized]

Investigate a possibility of adding the SSO login method to LastPass

[Sappharad]

Sorry for bringing this up so late.

I needed this last year, and being completely unaware of this new repository I forked your lastpass-sharp repository and added it. Because I did it for work, due to some miscommunication I didn't get approval to make my changes public and PR them until January, at which point I was very busy and didn't remember to make the PR until today. And then I discovered you had this repository which supersedes that one. The patch I developed follows below. (let me know if you want a PR for it to the original repo or not.)

The change is extremely simple, it literally just involves accepting 1 additional parameter then passing it to the server. All of the work to get that extra parameter differs based on the SSO provider. For example, I used the SSO fork of the lastpass CLI as a reference, and the developer of that fork had his own repository which had an implementation of Okta SSO. Unfortunately, I needed to login via Microsoft Azure ADFS SSO, so I had to do a little bit of my own reverse engineering to figure out how to generate the password and SSO fragment for that. There's not really a one size fits all solution. lastpasssharp_sso.txt

My implementation to handle Azure SSO has no company specific logic in it, so I can open source that as we'll, but it won't work for Okta or anything else. I will link the repo if you're interested. (see below)

How would you like me to proceed knowing this information? Do you just want to add the additional parameter to this library and I can confirm if it works or not? Should I fork this one and try to make the changes again with a PR when I have time? Or is your intent to try and support all SSO variants, somehow replicating the logic inside the browser plug-in? I believe it only had a few different providers that it supported.

Edit: I've committed the code for Azure ADFS SSO fragment fetching here: https://github.com/Sappharad/Lastpass-SSO-DotNET I would consider it "example" quality, it's certainly not intended to be user friendly since it literally just spawns a WebView2 for MFA then pulls the fragment out when done. There's very little in the way of error handling, but it was enough for my needs since I was using it internally for populating a login dialog for some UI test automation.

[detunized]

Hi. Thanks for your interest in this project. I understand I should have linked this repo from all the old not supported anymore libraries. Wanted, wanted, but never got to do that.

As far as the SSO support goes, I don't really understand it yet, what it is, what it does and how it works. I got a request from one user of this library and I added this ticket not to forget about it.

The things that I do know, I don't want to add any UI to this library. When I have to launch a browser I outsource it to the app by a way of providing some interface the app can implement. At this moment though, I'm thinking of refactoring the library to provide an async API with async two-way communication between the library and the application. This will allow the users to structure the code and implement the UI on the client side easier and more conveniently. Before I add this, I would like to avoid adding any new user interaction related interfaces.

Summing all of the above, given the fact that I don't really understand SSO yet, I would consider adding the parameter if it enables some new features for this library and if it's realistic for the users to implement the necessary part on their end and add to their app and just pass it down to the library.

[Sappharad]

I agree that it doesn't make sense for you add a UI to the library. This is why in the patch I linked above the only change involves the "SSO Fragment" variable that the caller would be responsible for passing in. When I used the SSO fragment with lastpass-sharp, I made a separate library for the UI portion of it.

I'll just explain SSO in case it helps.

SSO is an abbreviation for Single Sign On. It allows a user to sign into one account and use that account for other apps or websites that would normally require separate accounts. In the case of Azure Active Directory (Azure AD), this is used by many large companies who have Microsoft servers for user accounts and email. When a Windows machine is set up for corporate domain sign-in, a user logging into their Windows machine automatically gets authenticated on their PC and that user no longer needs to login again with their username & password for apps that support SSO. This is only possible between companies / organizations that have set up support for it behind the scenes - both the product being logged into and the user's organization's servers will do the communication behind the scenes to validate who the user is.

In the case of LastPass, SSO is only available for organizations that have purchased enterprise licenses for their users and the admin for that organization has configured their servers & LastPass to trust each other behind the scenes.

Microsoft ADFS is only one form of SSO. Technically websites with buttons like "Sign in with Facebook" or "Sign in with your Google Account" are also considered SSO since you're using one set of credentials to login, but it's not as nice as being able to log into a Windows machine and not have to enter credentials again to use LastPass.

-- Back to the topic of LastPass again - the way SSO works for employees at a company is as follows:

• Employee opens the browser plug-in, and if this is the first time using it they enter their work email into the username field.
• LastPass's server looks at the domain name of the email address and if it's a domain for a company with SSO support the browser plug-in makes a call to the user's company's server to authenticate them. There is some communication behind the scenes between LastPass and the Company server as well.
• If the employee is authenticated successfully, the company server provides a secret key and the LastPass plug-in is redirected back to LastPass's server which provides an additional secret key and a fragment.
• Some math is performed on the secret keys from the company server and the LastPass server and together the two keys are used to calculate a 'password' which will be used as the password for LastPass. That calculated password along with the SSO fragment from the login call is passed to the original LastPass login process and everything works as normal from there on.

In other words, SSO users, even though they are never prompted for a password, LastPass has a secret password calculated for those users behind the scenes. If someone wants to use your library with SSO they will need their own means of getting the password and SSO fragment values because how those values are obtained behind the scenes will be different depending on the login provider used. Many SSO providers also have MFA, so even if the user does not need to enter their password again they might need to approve the login or enter a code.

I hope this made sense.

[detunized]

Thank you very much for taking the time and providing such a detailed explanation. That definitely helps. I wish everyone on Github took their time to explain things like you did.

I could certainly add that fragment to the parameters but I guess I would have to find a way to test this somehow. And I imagine settings all this up is a nightmare. Do you have a way of testing this in your infrastructure to see if it works?

[Sappharad]

Yes, I can try to test it. The patch I provided for the old library worked for me, so I have no reason to doubt the same approach should work here.

[ayprof]

Anything ever come from this? Looking to use the lastpass cli but not able to due to Azure SSO.

[detunized]

@ayprof This has not been worked on. This is an open source project. Pull requests are welcome.

[Sappharad]

The stuff I posted earlier in the thread was still working at the time I posted it. But my employer switched away from LastPass after LastPass had multiple security breaches last year, so I can no longer test if someone wanted to try and incorporate those changes.

The information should still be useful though. Good luck if anyone wants to try and use it.