I have deployed keycloak as a standalone server and wanted to load test on it. I have very less knowledge about how to load test using jmeter. Gone through this resource but it is hard for me to understand it.
Can anybody explain on how can i actually do it ?
EDIT: I made a simple api that will authenticate using keycloak. So what i did is deploy the api in another server and used jmeter to get the auth token from keycloak and use that token to authenticate to the api. I did as much threads as possible as a way of load testing.
Related
I am developing an application which allows the user to download data from this remote database server. My server sode contacts another database server, get&package all the data, and send the data back to the client side. Everything works fine locally. However, when I deploy my code to AWS Elastic Beanstalk, I get a HTTP 504: Gateway Timeout, if my request doesn't get a respond in 60 seconds (when the data is too large and it takes more time to get all the data).
I have looked up a lot of posts online, but most solutions had to do with using a load balancer. I am not currently using a load balancer, and I am not really sure how to proceed with my issue. I know what I have to do is to change the timeout/idle limit, but I can't seem to find a resource that gives me insight on how to do that when I am not using a load balancer.
To give a main idea of how the project is built, it is written in ReactJS and Java, and it connects to a remote database server to request data. I am not using CORS/proxy, but using the Java backend code to have my server contacting the database server when I request for data. I am also using annotations in Spring framework for my requests (and more specifically, the controller class).
If you have any ideas on how to solve this issue, please let me know. I really don't know much about web application development. Thanks in advance!
I have a requirement where I have to schedule a console application, which fetches certain records from database and calls an ASP.NET web API. Could someone help me with how to restrict the web API to not get called from anywhere else?
Please help me with any useful links, tips, or steps to follow.
There are a few ways you can lock down access to your application for an rpc call.
You can restrict access via IP with IP filtering.
If you're using windows authentication, you can grant permission to specific AD User or Groups in your web config file.
If you're using forms authentication and basically just need to make an RPC call, you can create an endpoint for your console app which accepts a username/password parameter (using https, of course).
If your setup is more advanced, you can use tokens and ASPNET Identity to limit access.
These are just a few ideas. Basically just google ASPNET security and you'll get a ton of ideas.
Can anyone Tell me if it is possible to combine SSO from Spnego and Spring security with Oauth
This is my problem :
The Client I now represent has chosen Spnego as their SSO solution.
This requires us to use a full blown appServer (Liberty) in all scenarios.
At the same time, the knowlegde and skills about Spnego in the developent team is very limited.
Due to issues with creating the keytab files, Spnego is only available in the formal test environment and not our local test enviroment.
This makes it very difficult/time consuming to test and devlop due to the long deployment time to the formal test enviroment.
Not over to my question:
If possible I would like to be able to "log in" to a service in the formal test enviroment (OAUTH2 authentication server ?) using SPNEGO SSO and get a token back that I can use in further requests towards my services located locally and/or in any other test enviroment.
Is this even possible ? I have not seen any examples where the authenticantionServer is using another sso provider to actually authenticate the user.
A different possibility might be to to do some sort of redirect from the login service in the test environment but I fear the Spnego token created only will be valid on a sever in the same domain..
I`m sorry if this question is confusing or not clear.
My knowledge of this domain (security) is limited and I struggle to get a grasp of how I can test my code locally with security enabled.
Links to any resources on the net that addresses some of these issues will be greatly appreciated.
I am setting up an API for a mobile app (and down the line a website). I want to use oAuth 2.0 for authentication of the mobile client. To optimize my server setup, I wanted to setup an oAuth server (Lumen) separate from the API server (Laravel). Also, my db also lives on its own separate server.
My question is, if using separate servers and a package like lucadegasperi/oauth2-server-laravel do I need to have the package running on both server?
I am assuming this would be the case because the oAuth server will handle all of the authentication to get the access token and refresh access token functions. But then the API server will need to check the access token on protected endpoints.
Am I correct with the above assumptions? I have read so many different people recommending the oAuth server be separate from the API server, but I can't find any tutorials about how the multi-server dynamic works.
BONUS: I am migrating my DB from my API server, so I would assume I would need the oAuth packages migrations to be run from the API server also. Correct?
I have developed a web app that does its own user authentication and session management. I keep some data in Elasticsearch and now want to access it with Kibana.
Elasticsearch offers a RESTful web API without any authentication and Kibana is a purely browser side Javascript application that accesses Elasticsearch by direct AJAX calls. That is, there is no "Kibana server", just static HTML and Javascript.
My question is: How do I best implement common user sign on between the existing web app and Elasticsearch?
I am interested in specific Elasticsearch/Kibana solutions, but also in generic designs for single sign on to web apps and the external web APIs they use.
It seems the recommended way to secure Elasticsearch/Kibana is to have an Apache or Nginx reverse proxy in front that does SSL termination and user authentication (Basic auth). However, this doesn't play too well with the HTML form user authentication in my existing web app. Ideally I would like the user to sign on using the web app, and then be allowed direct access to the Elasticsearch API as well.
Solutions I've thought of so far:
Proxy everything in the web app: Have all calls go to the web app (server) which does the authentication, and have the web app issue the same request to the Elasticsearch web API and forward the response back to the browser.
Have the web app (server) store session info that Apache or Nginx somehow can look up and use to authorize access to the reverse proxy.
Ditch web app sign on and use basic auth for everything.
Note that this is a single installation, so I don't really need any federated SSO solutions.
My feeling is that the proxy within web app (#1) is a common generic solution, but it seems a bit heavyweight to have everything pass through the possibly slow web app, considering that Kibana uses the Elasticsearch API directly.
I haven't found an out of the box solution designed for the proxy authentication setup (#2). My idea is to have the web app store session info in memcache or the like and use some facility in the web server (Apache or Nginx) to look up the session based on a cookie and allow proxy access if authenticated.
The issue seems similar to serving static files directly using the web server (Apache or Nginx) while authenticating using a slow web app. Recommendations I've found for that are however very specific to that issue, like X-Sendfile.
You could use a sessionToken. This is a quite generic solution. Let me explain this. When the user logs in, you store a random string an pass him back to him. Each time the user tries to interact with your api you ask for the session Token you gave him. If it matches, you provide the service he is asking for, else, you just ignore his call. You should make session token expire in a certain interval of time and make a new one each time the user logs back in.
Hope this helps you.