I am working on a site where users can login to get more private information.
My client has another site else where that uses nt authentication for accessing it.
What they want to do is have a button on the site I am working on under the private area that will send them to the nt authenticated site, but not require them to log on to that site instead passing the username and password that they used to log into my site to the other site for them.
Is it possible to do this? and how would I accomplish it? Is there a better way to do this?
Here's an (untested) theory, the details of which will greatly depend on what types of authentication the Sharepoint site will accept. I'll tackle Basic, since it's the easiest.
You'll write out some JavaScript that uses XMLHttpRequest to submit a request to the Sharepoint site, and add their username and password to the request headers. Their browser will run that JavaScript, and get logged into the Sharepoint site.
Now, when they click the link, the client's browser should have the cached credentials to send to the Sharepoint site.
Possible issues:
XMLHttpRequest does not allow cross domain auth
Browser and XHR don't share auth info
Sharepoint and XHR can't agree on auth method
Another option is to proxy the connection to Sharepoint, which allows you to login server side (bypassing XHR limitations and browser security) - but requiring load on your server and possibly some URL target issues.
How will the other site validate your username and password?
Ideally your site shouldn't even be remembering the user's password to be able to pass it to another site (you store hashes of the password, not the password itself, and only use the actually password during validation).
What if your site provided a token to the user, who presents that token to the new site, which in turn asks your site to validate the token. Basically the second site is trusting you to tell them who the user is.
This all breaks down if the second site is actually using the Windows accounts for anything other than just retrieving a user name (for example permissions on the underlying file), since the user is not logged on as the actual Windows user account in this scenario.
If you need to authenticate against the second site, you may need to spawn a new thread and call the windows LogonUser API. Once you have the security token, assign it to the new thread and do your connection via that thread.
LogonUser requires enhanced privileges, and isn't Managed code, so there are some pretty severe hiccups to using it. But that's been the only work around I've been able to find to get a Forms authenticated site talking to a Windows Authenticated Service/Site.
Hope this helps.
Is this an intranet environment? If so they shouldn't have to login anyways. If sharepoint is setup using "Integrated Authentication" and the site is listed as a trusted site in IE, the browser will use there network cred for auto login. This can be setup on firefox as well.
Your users will not be able to connect to the NTLM site directly without getting an NTLM challenge. I would write what would effectively be a proxy to the NTLM site; i.e your server-side code will have credentials to connect to the NTLM site, and it passes through the requests from your users.
As you mention it's SharePoint (spit) bear in mind that SharePoint has a bunch of Web Services you could use for this (rather than doing screen-scraping).
Related
I am wondering if there is anyway to check if the entered username and password is correct despite of enforcing multi factor authentication in Azure Active Directory?
I have set up an app with application permission(with admin consent) as well as delegated permission and is able to test both approach using ConfidentialClient and PublicClient using MSAL library.
I am not able to run my web form app in IIS with the PublicClient approach which is interactive and displays you a popup for the Microsoft login. So, the only approach I see here is to use app-only authentication.(https://learn.microsoft.com/en-us/exchange/client-developer/exchange-web-services/how-to-authenticate-an-ews-application-by-using-oauth )
I can use the confidential client(app only) since I have all the required admin consents granted to get the OAuth token and then impersonate the user to access to EWS managed api.
But the requirement is the user should enter their outlook password in the webform app before loading their emails(from EWS Managed API which needs OAuth token).
At this point I am not sure what to do next. Please help. Also let me know if you need more information.
For more reference why I am no able to use delegated authentication: Why app is throwing error in test environment but working fine in local machine using ASP.NET Web Forms and MSAL?
Per my understanding, you want to check the username and password by Azure AD first and using the confidential client to call APIs on behalf of the user.
This way is something hacking, but I think it works for this scenario. Just try the request below:
POST https://login.microsoftonline.com/<tenant id>/oauth2/v2.0/token
Request Body:
client_id=<confidential client app id>
&Client_secret=<confidential client app sec>
&grant_type=password
&scope=https://graph.microsoft.com/user.read
&username=<username>
&password=<password>
If the user typed the wrong user name and password, the response would be:
If username and password are all right, the response report the MFA related info:
I am currently developing an SPA application that connects to a bunch of webAPI's. These API require that the user is logged in, so I started digging into Openid Conect and OAuth2 examples, mostly using IdentityServer.
They all require, for SPA reasons, that the implicit grant should be used for retrieving access_tokens. Token refreshes are handled connecting to authentication server using hidden iframe.
What I understand from this approach o renewing your access_token is that, sessions is maintained at authentication service. Hidden iframe goes to the authentication server, sessions is still active, new access_token is provided.
All that looks good for me, except (for UX reasosn) the fact that my user needs to be redirected to authentication server page for providing credentials.
Isn't it possible to have my SPA application send credentials to authentication server, getting the access_token, and then do the refresh using the hidden iframe for silently renewing (we, obviously dont want the user to keep informing credentials every 15 minutes or every hour..).
If this is not acceptable for security reasons, could you please explain why?
Technically it is possible with "resource owner password flow", but in that model identity provider can not trust your application and will not create a session for your user (to use silent renew later on). Thus such non-interactive approach is not truly SSO. For 2019 the recommended flow for any web app such as Angular SPA is Code flow with PKCE extension, as described here or there.
EDIT:
Editing this answer to correctly reflect the requirement.
If the requirement is not to show authentication server page and use your own SPA, the only possible way to do it is using "Resource owner password flow" with the constraints mentioned in the previous answer
This is discouraged for two reasons:
Security - Will the SPA have the same security controls as the "Authentication server" has in handling passwords of the user. Right from collection to management of the user password (safely securing for future calls ?). This will massively impact the scope of SPA and it is one of the main reasons why people prefer federated logins (outsourcing login complexity to the third party - in your case authentications server)
Trust - How would you convince the user to handout the "authentication server" password to a relatively new SPA app. Imagine if Google / Facebook allows this pattern for a SPA to collect password instead of redirecting to the Google / Facebook login page. This is a recipe for disaster.
This is exactly what oidc-client-js library does. Have a look at automaticSilentRenew settings in their wiki page. Understandably this only works as long as the session at the authentication server is still active.
There is a WebAPI hosted in IIS. It is using Windows authentification with NTLM protocol only. If I am trying to reach it with chrome extension which gives me the ability to send REST requests, chrome prompts me for credentials and this is the part I dont understand why? Windows auth is the one that should take my information from my windows login isnt it? It is not forms auth. Of course it happens the first time only, if you are reaching it multiple times it just returns the token, but I guess its just the session things.
I feel that I am missing something and dont have enough knowledge about it so any information would be nice.
Question:
Why windows auth is prompting for credentials when I am trying to authenticate to my WebAPI the first time? Shouldnt it handle this automatically based on my windows login information?
Thank you
Windows authentication means it will validate the username and password of the user available in the directory listing of the hosted server.
And after you enter the credentials once then the browser will manage it further.
If you close that tab and open the url in new tab then also it will not prompt again unless the browser is not closed and reopened.
It is not possible to handle windows login automatically without login prompt box.
I'm working on a password management system which stores the passwords of a bunch of services (gmail, bank of america account, youtube etc). The user will be able to launch each of these services by logging into my application. The application will then POST the username and password associated with that service to that service's login url in a new tab and you will be immediately logged in. My question is, this method exposes the actual password of the user to the client side (since I'm creating a form with username and password, in plain text, as hidden fields and calling form.submit). I'm wondering is there any other method by which this can be achieved? How do all the password management sites work? Your help is appreciated.
Do it server side, what else can I say? Anyway, I can only see this as a learning experience, not something that would eventually go into production. cUrl could be a good start. Why do you use form.submit anyway?
This is called "formfill" in terms of access management terminology, if you are thinking about access gateway (http). If you are thinking about browser plugin, have a look at the firefox autofill plugin. And which finally reduces to single sign-on.
Single sign-on are done different ways,-
some servers uses active directory to store all the passwords and later access using the master password , i.e. the active directory password of that user to access his credentials.
Some uses SAML
Some uses e-directory
Whatever you use, if it is server-side application (e.g. Appache supports formfill), it parses all the forms based on form name or resource path and fills credentials based on the authenticated session from the user.
So a bit of background, I'm working on an existing web application which has a set of users, who are able to log in via a traditional login screen with a user name and password, etc.
Recently we've managed to score a client (who have their own Intranet site), who are wanting to be able to have their users log into their Intranet site, and then have their users click a link on their Intranet which redirects to our application and logs them into it automatically.
I've had two suggestions on how to implement this so far:
Create a URL which takes 2 parameters (which are "username" and "password") and have the Intranet site pass those parameters to us (our connection is via SSL/TLS so it's all encrypted). This would work fine, but it seems a little "hacky", and also means that the logins and passwords have to be the same on both systems (and having to write some kind of web service which can update the passwords for users - which also seems a bit insecure)
Provide a token to the Intranet, so when the client clicks on a link on the Intranet, it sends the token to us, along with the user name (and no password) which means they're authenticated. Again, this sounds a bit hacky as isn't that essentially the same as providing everyone with the same password to log in?
So to summarise, I'm after the following things:
A way for the users who are already authenticated on the Intranet to log into our system without too much messing around, and without using an external system to authenticate, i.e. LDAP / Kerberos
Something which isn't too specific to this client, and can easily be implemented by other Intranets to log in
Both of your suggested options are insecure, even if you use SSL. Never pass credentials on a URL, put them in the HTTP request by using POST.
There is a standard called SAML and this can be used to solve your problem. The challenge is choosing which version to implement. I would choose SAML 2.0.
Google Apps implements a flavor of SAML 2.0 and allow you to authenticate using your intranet credentials. In the case of your application, you would be the service provider and your client would be the identity provider. As long as you implement the standard correctly you should be able to support any new client (identity provider). Here is a list of SAML implementations you might want to take a look at. If you need the client to pass over information in addition to the authentication information then SAML can facilitate this with metadata.
You will still need to implement SSL to encrypt network traffic.
I hate to answer my own question, but I hate even more a question with no answer. In the end we went with a very similar implementation of SalesForce's delegated authentication SSO implementation.
http://wiki.developerforce.com/page/How_to_Implement_Single_Sign-On_with_Force.com
Essentially the solution has a trusted site, known as the delegated authentication authority, who has a list of users who are logged into the company intranet.
When the user logs into the company intranet, and they click a link to our application, the company intranet will pass the user name and a generated token (which expires after a set amount of time) to our application.
Our application will then check if the user name is on our site, and if so, send the username / token (along with the source IP and a few other parameters) to the delegated authentication authority. If all those items match on the delegated authentication authority, it returns true and the user can log in. If it returns false the user is denied access.
We've found this system to work quite well, and even implemented a couple of extra security features like SSL, client side certificates, VPN tunnel, and even restricting the IP addresses which can access the site and the delegated authentication authority.
I know it's bad form to answer your own question but I hope this helps someone else who might be having the same problem ...