There are multiple requests being passed in signing in of the application since its using Sitefinity - Azure AD B2C Authentication and there are some values being passed in each requests such as nonce, state properties, id token etc. The workflow is quite complicated when having a peek into the values/token being passed across the requests of login. Though I have created/tried with all the values that are getting as the response of previous requests, still the login is not happening. Also, I went through some documents of B2C authentication with Sitefinity and its architecture and I got to know that the token being generated by the Sitefinity is an internal process and the response of that token cannot be fetched from a previous response/ client side.
Workarounds that I did:
Integrated selenium into Jmeter and automated the login scenarios and stored the cookie generated. Then used these cookie and token in following internal requests- This approach worked fine.
Hardcoded a live cookie in Cookie Manager and send the internal requests - This also worked fine.
I am wondering if there is any other possibilities in logging in because the above two methods are not reliable in long run. Anyone have idea about generating the token id locally and pass that to JMeter. for example creating a .exe file which generates the Sitefinity token.With this we will be able to pass or execute the .exe file in OS Process Sampler in Jmeter and fetching the token from its response.
Or
Any other approach?
I assume you are using the OpenIdConnect authentication provider that is built into Sitefinity?
So, basically when a user clicks on the Login button, he is being redirected to:
/login/LoginExternalProvider/OpenIdConnect/
Here Sitefinity replies with a redirection to:
/Sitefinity/Authenticate/OpenID/connect/authorize?client_id=sitefinity&....
which in turn redirects to
/Sitefinity/Authenticate/OpenID/login?signin=....
and this finally redirects to the external authentication provider.
(yeah, it is a complex workflow).
So, if you try to load test only the first request (/login/LoginExternalProvider/OpenIdConnect/) - wouldn't it then follow the redirect responses automatically (sorry, not familiar with jmeter)?
Those responses contain the correct cookies that Sitefinity has created, etc.
As per Sitefinity documentation:
Sitefinity CMS uses claims authentication, implemented on top of IdentityServer3, certified by OpenID Foundation. It allows implementing single sign-on and access control for modern web applications and APIs. It uses OAuth2 and OpenID Connect protocols.
Standardized authentication, based on OpenID Connect with JWT, certified IdentityServer3.
Given you're capable of logging in using your browser - you can replicate the same requests using JMeter's HTTP Request samplers, it's just a matter of correlation - the process of extracting the dynamic data from the responses and using them in the next requests.
You can refer OpenID Connect - How to Load Test with JMeter article for example JMeter script implementation
Related
I am performing the Jmeter load testing. Our application is on Oauth authentication. How can i logging using Jmeter so that we can perform load testing on our application.
Right now we are not able to set parameters on "HTTP Authorization Manager" for login.
You won't be able to use HTTP Authorization Manager, you need to pass the Bearer token via HTTP Header Manager.
With regards to the token value - there are several ways of getting it, they depend on OAuth version and your application configuration, you need to contact your application developers in order to learn how you can obtain the token.
You can also check out How to Run Performance Tests on OAuth Secured Apps with JMeter article for several workarounds listed and explained.
I have a RESTful API written in ASP.Net that implements OAuth 2 for authentication, and it's currently accessed through a web application. I've also got a legacy desktop client that accesses the same resources directly (not through the RESTful API and without OAuth, but using the same login credentials and hitting the same database). The requirement I'm trying to meet right now is to allow a user to click a link in the desktop application in order to open the web app to a specific screen, and when they do, to have the web app authenticate automatically so that they don't have to manually log into it (since they've already logged into the desktop app).
I'm trying to work out how I can handle this within the constraints of the framework. I'm not too familiar with OAuth 2 in general, but from what I understand I shouldn't share tokens between clients and there are no flows specifically for this kind of hand-off (unless I'm missing something). Worst case scenario, I could generate a temporary token outside of OAuth that's used by the web client to authenticate rather than a username and password, but I'm hoping to avoid stepping outside of what's already in the framework to do what I need to do.
So the question is this: is there some decent way built into the OAuth 2.0 framework to handle this sort of "handshake" between two applications, or should I just build my own method of dealing with it?
Using temporary one-time tokens is actually part of OAuth spec (authorization_code grant type). In this case this short-lived code can be exchanged for access_token (and refresh_token). You will have to implemenent generating and validating of this authorization_code.
If you are using OWIN OAuth middleware:
You can generate the code at separate API endpoint accessed by your desktop client app.
After receiving token, pass it to your browser and direct it to auth endpoint with grant_type=authorization_code over secure connection. Example: call Process.Start("https://example.com/ExternalLogin/authorization_code_goes_here"). At the webpage redirect user to your OAuth Token endpoint with grant_type=authorization_code.
AuthenticationTokenProvider.Receive will be called, in which you will validate your token. (Example code here).
After successful validation OAuthAuthorizationServerProvider.GrantAuthorizationCode will be called, in which you will process the authenticated user in the same way you process it with grant_type=password.
Remember that your token validation logic should ensure that your tokens are short-lived, usable only once and transmitted over secure connection.
This is sometimes called "single sign-on" if you want to research this topic further.
I have to start a new project to be developed in MVC 4 and Web API. I have prior experience with MVC 4 but with Web API this will be my first project. I understand that web api is there to be consumed by different platforms.
I have a few concerns related to web api. I am presenting them to you guys as following:
1) My first concern is related to user authentication. I looked into this SO question and followed the link1 and link2 given in the selected answer. I still have a couple of questions:
a) When we do user authentication through Form Authentication we create a cookie, that track if the user is authenticated or not, but with web api we do not store cookie, instead user credentials are passed in content header. I didn't get how user's logged in status is tracked in this case ?
b) My another concern is related to restrict unauthorized access, which I think I can find find out in link 1 and link2 provided above, if I am not wrong.
c) I looked at the Edward Brey answer (in the same SO question) as well for authentication but I didn't get the idea completely.
2) My second doubt is about mixing Form authentication and Basic Http authentication. Is it possible that for login I use forms authentication and then for consuming web api I use basic http authentication? If yes then please guide me.
My questions may sound inappropriate but please bear with me
1.a) Restful APIs are stateless, so you are not keeping track of user's logged in status, rather you are sending credentials which are verified for each of the requests
1.b) Yes, if not there are number of articles on web for that. Authorization Filters can help you in achieving this.
1.c) In short, he has mentioned simple logic to authorize user before executing any of the methods in your API. Call EnsureAuthenticated before executing any of the methods in a controller, or put that logic in you Authorize filter.
2) Yes you can do it. In Restful API's each call can be a new instance and you can pass in credentials with api requests whichever you are making.
If you go in discussion of Link 1 that you have provided, you will see:
In our specific case, the server generates the auth token by encoding
the concatenated username and password as Base64 (the reverse of what
is described in the article) and sending it back to the client via a
HTTP header when it performs their ‘log in’ action. The clients then
store this auth token and send it with each subsequent request that
requires it.
If the format of the auth token is well known (as it is in my case),
you could also just generate this yourself on the client and send that
without having the server do this work.
You can use your login to generate an authentication token for client, which you can use to send attached to your web api requests.
I'm using VS2013 and Web API 2 to create a self-hosted (using OWIN), RESTful service over SSL using token authentication. Although I'm not a novice developer, this is my first time looking at ASP.NET technologies, so please keep that in mind.
I've got everything more-or-less working except for the authentication and authorisation parts. I fully understand the difference of authenticating a user (who is this user?) and authorising an already authenticated user to access a resource (can this user access this particular resource?).
A very simple overview of my auth process is as follows (makes some assumptions for brevity):
An unknown client connects to the API, e.g. GET api/values.
The server responds with a 401 and this response header: "WWW-Authenticate: Token".
Upon seeing this, the unknown client knows to connect to a different API endpoint here: POST api/auth (routed to the Login function), supplying the username and password.
The server will try to figure out if this is a valid user and can accept or reject the user depending on the validity of the credentials.
(Rejected) The server returns an error status code (403?). End of process.
(Accepted) The server creates a random token (e.g. a GUID) and stores it against the user record. Then it sends the token to the client.
The now authenticated client reconnects to the API, GET api/values, and this time also supplies the token.
The user returns the resource data to the client.
...
The user can log out by connecting to the same API as he used to log in: POST api/auth (this time, his request will be routed to the Logout function). This will remove the token from the server and the client will also have to remove its own token.
As you can see, this is a relatively simple process, but I can't find any concrete and simple examples to understand how best to achieve this with a self-hosted Web API 2.
I don't need to register users or do any password/roles management, etc. and there is no external authentication. All valid users have the same rights to access the resources and they're already created in the system by a separate process over which I have no control (I can only read their credentials for validation). Most examples I found are talking about security frameworks that I don't need, so I've ruled out using any of the following: Basic Authentication, Windows Authentication, Forms Authentication, Individual Accounts, ASP.NET Membership/Identity, OAuth, Thinktecture or any other security framework.
I've read articles about authenticating in a message handler and others about authentication in a custom Authorize attribute filter, while others even suggest I should use the new (in Web API 2) IAuthenticateFilter attribute. This is very confusing. Can you please advise on a very simple way to achieve my auth objectives? Any specific code examples will be greatly appreciated, even if they're just skeleton implementation or pseudocode. I just need some ideas to get me started.
After a lot of googling, I found this article on CodeProject: http://www.codeproject.com/Articles/630986/Cross-Platform-Authentication-With-ASP-NET-Web-API. While this is not Web API 2 or self-hosted, it has given me a number of ideas on how to proceed.
Someone also posted a comment to that CodeProject article referencing a NuGet package that may interest anyone looking for something similar: https://www.nuget.org/packages/WebApiTokenAuth. In my case, it is a bit much.
Finally, in addition to the authentication options mentioned in the question, there's also the option to write an OWIN middleware to do authentication if self-hosting using OWIN (as per the official MS recommendation). However, I plan to implement this particular form of token authentication with a message handler, as there's more support for this method available than for writing OWIN middleware.
Here's the situation, I've got a console application that needs to run once a day and make a few requests to pages that require authentication to view. The pages are hosted in a really basic ASP.Net Web Application.
So, I know that in order for the requests to go through successfully I have to authenticate with the server. So I've hooked up the console application to the ASP.Net Membership Provider I'm using for the web app and it successfully determines if a set of a credentials are valid. However, after calling Membership.ValidateUser() any requests I make just get the login screen. After doing some reading it seems that this is because I'm missing the important cookie information that persists my login or what-have-you.
I'm using a basic WebClient to make the requests and then reading/discarding the result.
So the meat of the question is this: Is there a simple way to validate the login information and hold on to it so that I can make the requests successfully, or is this the exact same case as the other two questions I found that require the WebClient to make a "manual" login request to the login.aspx page and try to hold on to the cookie from there?
The questions I'm referencing are:
Authenticating ASP.NET MVC user from a WPF application
and
Login to website and use cookie to get source for another page
With FormsAuthentication the webserver has to generate a Forms Authentication Ticket for you. The best (only?) way to do this is to log into the site, so I'd just log in like the other questions.
If the intent is to send data to the server and/or get data from the server, then the most logical architecture is probably to create a web service using either ASMX or WCF. Then configure the service to use a security token, such as a username token or a SAML token. This will make the client less likely to break when the server code changes its data model.
Otherwise, if you wish to use only a basic WebClient, then you will have to find a way to pass your credentials to the login page and retain the login cookie that is returned from the login request. Then, make sure that the login cookie is included on all subsequent requets, similar to the Stack Overflow question that you referenced, "Login to website and use cookie to get source for another page".