I'm writing some load tests against a restricted web server on our local domain. The webserver requires entering network credentials to be able to access sites on the server. How do I automate my network login? Again, this is a server login, not a website login form.
Found the answer. This MSDN ariticle explains how to set credentials for a web site that uses basic authentication or Integrated Windows authentication.
http://msdn.microsoft.com/en-us/library/ms182548.aspx
Related
My team writes a monitoring system which we have recently migrated the definitions of our monitoring into a git repo. These definitions are comprised of some json and powershell files. VSCode is an ideal scenario for editing and dealing with git. The problem is while developing the monitoring it is nice to be able to execute it against a test environment. Previously all editing was done through a web interface and we allowed ad hoc execution of the powershell against test machines through an API which is secured with AzureAD and OAuth2.0.
VS Code extensions don't have access to the full electron api and you are restricted from creating a BrowserWindow to handle the usual OAuth redirect flow. Is there a way to work around this limitation and allow a user to auth to our api so that we can make calls to it?
Any ideas or possible workarounds would be awesome.
One thing you can do is to use Server to Server via Client Credentials authentication method. There is node npm library here.
You will need to first register your VS code extension into Azure AD via Azure Portal.
The downside of this method is the credential passed to the Web API won't be user's credential but rather same extension specific credentials. But it would be OK in case you don't need VS code user's identity.
The supported way to get a user token for an application that doesn't have the ability to open a Web Browser to auth is the "OAuth Device Flow". Here is a link to a blog about how to implement it with AAD.
https://joonasw.net/view/device-code-flow
You need to host a localhost webserver inside your extension, when you're doing the auth and then pass localhost:port as the redirect URI for the oauth login flow.
I have developed an API using ASP.NET Web API 2 to be consumed by applications in my domain. I want to secure the access to the API endpoints. I've decided to use the OAuth token based token authentication for mobile app clients and web app clients.
However there are some non-interactive windows service clients that need to consume the API. I do not want to store login credentials to get a token in the service config, however a Windows authentication suits this type of client.
Is it possible to use a hybrid - windows and token-based authentication in ASP.NET WebApi? How?
I think the Windows authentication service from Identityserver might be a good solution for your problem
You can find more information on : WindowsAuthentication repo
I have decided to break up the API into two. One for normal OAuth based access and the other with specific resources using Windows authentication to be consumed by non-interactive windows service clients.
I'm working on a web application that works with the TFS API and I would like to make sure that any users that use it have the proper authentication to use TFS.
To do so I use the following code:
TfsTeamProjectCollection teamProjectCollection = configServer.GetTeamProjectCollection(collectionId);
teamProjectCollection.EnsureAuthenticated;
I'm going to host the website on IIS.
When a user uses the web app, will EnsureAuthenticated use their credentials, or will it use the credentials of the remote desktop I'm hosting the application on?
It depends.
If you have configured ASP.NEt to use impersonation, it will use the account of the logged user.
If ASP.NET is configured with default settings there are a number of things that can happen
If there is a credential stored in the Credentials Manager it will use that
If the application pool is running under a real account it will try to do that
If the application pool is running an application pool account, it will probably try to authenticate with the System's account (COMPUTER$)
I'd say, try it and look at the IIS logs of your TFS server or use something like fiddler to capture the traffic.
is the SAML protocol (Sing Sign ON) used soley for web apps and web services, or is it also used for standard applications?
REVISED:
I am looking for some windows (Standard Applications (not web based)) protocols for Single Sign On
If you are looking at Windows specifically, why not use Kerberos and Integrated Windows Authentication? It's built into Active Directory and Domain Controllers. It doesn't really work once you start crossing into the Internet and different security domains but it works well behind your firewall in a corporate environment.
However, SAML can be used for desktop applications. I've run into applications before that would retrieve the Kerberos ticket from the Desktop, make a WSTrust/RST call to an STS to validate the Kerb token and get back a SAML token in the RSTR that would be embedded into a Web Services call that the desktop application needed to make.
SAML allows secure web domains to exchange user authentication and authorization data and by definition would require an internet connection to do so. So no you would not want to use it for a desktop application.
Revised
here are the links for active directory implementation with Delphi.
http://www.agnisoft.com/white_papers/active_directory.asp
http://adsi.mvps.org/adsi/Delphi/index.html
I'm publishing a public ASP.NET website. I'm assuming the visitor is using Windows and Internet Explorer. I want to display the Windows username on the front page, is it possible?
I have already enabled Windows Authentication in IIS and on a development environment everything works fine. On production it keeps asking the Windows login credentials.
For Windows Authentication, the user must supply credentials that can authenticate to the server/domain in which the website is running. If the client is running within the same domain and authenticated, Internet Explorer will automatically handle the credential exchange; this is why it works in the dev environment. However, when accessed from the public side, Internet Explorer tries to hand over the credentials that the user is currently using (some other Windows domain), but those credentials cannot authenticate to your sever, so IE prompts the user to enter credentials that can authenticate to that domain.
If it's a public website then you can't do it. Why? Because you would need to verify the user credentials against your AD and you can't do that on a public web page. (Which makes total sense, after all how would you know who I am otherwise?)
If you ARE doing this in an internal network where each account is in your Active Directory, then people just need to add the site to their Trusted Sites or Local Network Zone in IE for NTLM to work transparently.