how to check the Database used in loadrunner when sending a HTTP requests or getting Responses - postgresql

we used to use sap as DB for our raw data, when I make a load Test for example to get our business partner, all the requests access the sap dB, and I got the response of the business partners, when I send the following request code:
web_custom_request(MDM_GET_BUSINESS_PARTNER,
"URL={TEST_ENV_HOSTNAME}/api/v3/clients/{BUSINESS_CONTEXT}/customers/{GCID}/businessPartner",
"Method=GET",
"EncType=application/xml", "Resource=1",
"Referer=Loadrunner",
LAST);
Here as you can see there is no mention of SAP DB or whatever DB are used, and now we move (migrate) from SAP DB to PostgreSQL.
My question: how to check the HTTP Requests send and their Responses are using which DB's (SAP or PostgreSQL)? is there any method solution for that, because as you can see above, the request goes to the {TEST_ENV_HOSTNAME} which is a parameter file, and there is no mention of any DB.

Speak to your application architects. You are operating a one architectural tier removed from the database, at the web tier. So, only an architectural diagram can solve your information needs

Related

How to protect an API endpoint for reporting client-side JS errors against spam (if even necessary)?

I am developing a web application with Spring Boot and a React.js SPA, but my question is not specific to those libraries/frameworks, as i assume reporting client-side JS errors to the server (for logging and analyzing) must be a common operation for many modern web applications.
So, suppose we have a JS client application that catches an error and a REST endpoint /errors that takes a JSON object holding the relevant information about what happened. The client app sends the data to the server, it gets stored in a database (or whatever) and everyone's happy, right?
Now I am not, really. Because now I have an open (as in allowing unauthenticated create/write operations) API endpoint everyone with just a little knowledge could easily spam.
I might validate the structure of JSON data the endpoint accepts, but that doesn't really solve the problem.
In questions like "Open REST API attached to a database- what stops a bad actor spamming my db?" or "Secure Rest-Service before user authentification", there are suggestions such as:
access quotas (but I don't want to save IPs or anything to identify clients)
Captchas (useless for error reporting, obviously)
e-mail verification (same, just imagine that)
So my questions are:
Is there an elegant, commonly used strategy to secure such an endpoint?
Would a lightweight solution like validating the structure of the data be enough in practice?
Is all this even necessary? After all I won't advertise my error handling API endpoint with a banner in the app...
I’ve seen it done three different ways…
Assuming you are using OAuth 2 to secure your API. Stand up two
error endpoints.
For a logged in user, if an errors occurs you would
hit the /error endpoint, and would authenticate using the existing
user auth token.
For a visitor, you can expose a /clientError (or
named in a way that makes sense to you) endpoint that takes the
client_credentials token for the client app.
Secure the /error endpoint using an api key that would be scope for
access to the error endpoint only.
This key would be specific to the
client and would be pass in the header.
Use a 3rd party tool such as Raygun.io, or any APM tool, such as New Relic.

Record level access control for REST API GET Collection call

So, I am working on the next project that requires more detailed access control functionality (i.e. Sally can only view products in her department).
I get how either a role based access control model or an attribute access control model can 'wrap' an API call to determine if a given user can perform said action on a given object.
Where I keep getting stuck is when you are dealing with a GET call that returns a collection of records. If I ask the API for a page of 20 records from this endpoint, I can't get 20 records, then run a code based authorization check on those records before returning them as I most likely won't be returning 20 records.
It seems like the authorization check either has to be down in the database and/or happen prior to the database query by adding additional filters to the query call (i.e. also filter where product department = clothing).
Anybody have any more concrete implementation examples or ideas how how this could be implemented in a performant manner?
As David mentioned, XACML can be used at the database level for filtering.
Implementing XACML For The Database
The diagram below is for SQL, but can be used as a general example for any database technology.
Let's see how this works:
SQL statement is intercepted.
A query is sent to the external authorization service that implements XACML
The authorization engine (PDP) evaluates the relevant policies, written in XACML or ALFA (an implementation of XACML).
It may query external attribute sources (PIPs) for more info.
The result: SQL statement is dynamically modified to retrieve only authorized data for the user.
How This Would Be Used In An Application
The implementation of XACML you choose to go with would ideally have an SDK in your language of choice or support the XACML REST profile. Either would work for integration into your application.
Given that you are using REST calls, I don't think you would have to add much code to integrate your application with an implementation of XACML.
Implementing XACML for an API Gateway
The principle used in this integration is the ability of an API gateway to make a callout to a third party service.
In this case the third party service is your XACML implementation's Policy Decision Point (PDP). The implementation must support REST/JSON.
The API Gateway is configured to send fine-grained authorization requests to the PDP.
Requests are made using the REST/JSON interface exposed by the PDP. The PDP then returns a response.
The JSON profile of XACML extends the Request/Response schema allowing both the Request and the Response to be encoded in JSON instead of the traditional XML encoding. This makes the Request and the Response much easier to read and also much smaller in size thus transferring less data.
Implementations of XACML
For an entire list of XACML implementations, you can check this list on Wikipedia.
Full disclosure - I work for Axiomatics with David Brossard, who designed the JSON profile for XACML to be used in conjunction with the REST profile.
Axiomatics provides Axiomatics Data Access Filter for relational databases and SmartGuard for HADOOP. Axiomatics Policy Server natively supports both JSON and REST profiles.

How to send response to a Command in CQRS?

I'm implementing a CQRS system with Akka persistence and I'm trying to understand the request response bit of CQRS.
There are few answers on SO on how to send response back to client and this article also mentions a few good patterns. But instead of generalising using big words can someone please explain how should I send response back to the client in CQRS for the following simple use case.
Use case
Suppose the user is on a page which displays users profile which displays the following information
Username
Address
Phone number
And In my system I have one Actor per User which stores that user's profile information.
On the UI user wants to update the address and the following things happen:
User makes an AJAX REST call to update address of user
UpdateUserAddressCommand(address:String) generated
UpdateUserAddressEvent(address:String) generated
UserAddressUpdatedEvent(updatedAddress:String) generated (state of the UserActor updated)
Now how do I send back the full state of UserProfile in the system ? Since CQRS discourages sending response for a Command ?
With respect to the CQRS pattern, the REST layer can be considered a client of the system using CQRS, and therefore you may send a response (from the REST server to the web browser) without violating a "principle".
In your case, it's quite simple:
REST call to /api/endpoint/1234 -> REST server generates the command as above.
Server returns code "202 Accepted" and sets the Location: header to
something like /api/user/profile/1234
Client queries /api/user/profile/1234 to query the full state of the UserProfile.
You can combine 3. with HTTP long polling if you are using asynchronous query side updates/eventual consistency.

REST API Security JBoss EAP 6.4

I am coding a webapp (E-commerce) for learning purpose using AngularJS + BootStrap and REST.
I have used Apache Wink for REST WS and and application is deployed on JBoss EAP 6.4. My application is working fine.
I can access the back end data using AJAX and webpages are getting populated properly. The issue is security of REST WAS. If I use REST URL directly on browser, without going through front end, JSON data gets populated and my data is exposed. What design changes should i do ?
Please note that initial operation on the website for e.g. browsing the products, adding them to cart etc are stateless. No user's identity is needed for these operations. I still need to secure my data for these interactions. Please suggest, how can I do it.
Sunil
If you want to lock down the services, you may require some type of authentication (for example user/pass) that returns a security token (over https). Then all subsequent function calls may require the security token to be passed in as a parameter (if the operation is sensitive). The token will require a session timeout.
However, if the data is also publically shown on the site, then there's not really a security risk in itself. IOW, how is this any different than them using the public website to get/update data? The rest services usually shouldn't require any additional level of security beyond what is already used on the website to protect the data.

Passing Shibboleth credentials after successful authentication

I have a high-level/conceptual question about Shibboleth.
I'm working on the front-end (running Drupal) of a data-driven web app. End-users interact with the front-end to construct data queries, which makes background requests to a caching/archiving data proxy (the "data retrieval service"), which in turn either delivers data from its cache or goes out and queries still more services ("out there") which have desired data. So far so good... it is ornate, but only as ornate as the problem we're trying to solve.
Here's the wrinkle: Some of services queried by the data retrieval service want to implement user-level authentication, so that some users may access their data, but others cannot. For organizational reasons, our identity and authentication mechanism is likely to be Shibboleth.
So, here's my scenario: a user logs in to the frontend using Shibboleth. Now, can my frontend, and in turn, the data retrieval service, authenticate against against external services as the user? And if so, how does that work in practice (what authentication data gets passed from server to server)?
Yes it can - you service has to exist in the identity provider (how it is set up is up to you)