How to pass Token while calling a RESTful Webservice in Informatica - informatica-powercenter

Need to call a RESTfull webservice from Informatica powercenter. it has a never expiring token for authorization.
Tried calling the webservie using HTTP transformation and passing the access token in the header. it works fine and webservice returns the result. But everyone can see the token once mapping is checked out.
How can we manage the token, store in encoded format or is there a away to create application connection to store the token ?

Here is what we do in Informatica world to protect the sensitive data like password and so on.
You store the value in a file and put it inside a folder.
Make the folder invisible / restrict access to read only for that informatica unix user and rest users have 0 permission.
Once it is done, create a parameter in the file and use that file as a parameter for the informatica mapping, so when ever the mapping runs, it will go and pick up the parameter from the file, which the informatica user can only read, and run the mapping .
This prevents
1. Hard coding sensitive elements in the mapping
2. Hiding the sensitive data from all other Unix users other than Informatica unix user, thereby protecting the data

Related

Onedrive OAuth 2.0 code flow for getting access token 'redirect uri' is not specified in the list of urls specified

Before adding, yes it works when I give the entire url like http://localhost:8080/onedrive/oauth2/success/1 in the list of uri in azure uris. I am using code flow to authroize these tokens.
But as per the docs, it should work with me just mentioning the domain name there, like http://localhost:8080. Which it doesn't.
I want to do something like send the user id along with every request for me to keep track of which user I should link this accees token to, and have no idea to do so, if this issue is there. My current application logic is, when my application sends the user details and calls my spring API, I want to handle all these transfer of tokens in the server side, so I want to transfer this userId as my path variable. How do I go about doing this? Has anyone done this, can they explain to me any other different solution?
You can't add custom details to OAuth redirects and it is best practice to always register the full redirect uri.
In terms of tracking the user, after login the token has a user id and you can also get fields such as user name and email - so both the UI and API will know which user each token is for. I can provide further details on mechanics if needed.
The user id in a token is often a generated value, whereas the user id you want to use in API path segments is maybe a user id from your app's back end database - if so you will need to map between token details and database details.
If you provide redirect uri as http://localhost:8080/ then it means you are handling the api response in
/
endpoint and not
/onedrive/oauth2/success/1
To get to know the user to whom you are linking, few ideas which you can use are
1) Use security to obtain the logged in user credentials (Ex: Principal if you're using Spring security in java)
2) After successful authentication, use the user id you have and send one more request to backend and store it database with userid as a key

Jmeter - Run multi-threaded users simultaneously without affecting the flow

I have a user flow (create base64 header auth > register request > Register > login > sending data) which I want to run simultaneously (100 users).
If I use the Thread Properties as it is, it will run in asynced way.
Examples:
User 3 will try to login with token of user 1, user 40 will register with registration header created for user 24 and so on..
Token for login extracted from base64 process,
another token is extracted from 'register-request' and used as variable in 'registration' header.
I want first user to register with token created in first register-request and login with token created in base64 process, and so on for next users.
Is there a way to do so?
Normally JMeter virtual users store variables in the thread-local storage so given your test plan design is good each thread (virtual user) should use its own header.
Not knowing the details of how your header is generated it's hard to say what's wrong, I would recommend using Debug Sampler and View Results Tree listener combination and double check the header value (and any interim variables) - hopefully you will be able to determine the cause. If not - you will need to share the test plan somewhere somehow.
Other things to consider:
If your application requires Auhtorization header in form of username:password encoded into Base64 you actually don't need to generate the header manually, you can use HTTP Authorization Manager which automatically generates and adds the relevant header to the requests. Check out How to Use HTTP Basic Authentication in JMeter article for more details if needed.
There is __base64Encode() function which you can use for encoding a custom string into Base64, the function can be installed as a part of Custom JMeter Functions bundle using JMeter Plugins Manager

Call Oracle Apex page and auto-log in from forms 12

I have Oracle APEX 5.1 and Oracle Forms 6i installed.
Now I am wondering how can I call Oracle APEX application from my Forms menu.
Option 1: Full URL to aplication + parameters username/password - not safe
Option 2: Full URL to aplication log in - not elegant.
What I am looking for is function that will take parameters username,password, aplication ID, ... and return full URL to aplication.
Is that possible / best approach?
You would probably do best to look at a new way of authenticating that avoids needing the password altogether, yet remains secure. One way is to call a procedure from the Forms application that generates a single-use, short-lived token specific to the user, then pass that token to APEX along with the username. The APEX authentication scheme then checks that the token is current and valid for the user, and if so allows access.
For example, the token could be generated as a random string, and stored on the user database record in hashed form (combined with the username as salt) along with a timestamp of when it was generated. The authentication scheme checks that the token passed is the same as the one on the user record and that the timestamp on the user record is within the last N seconds. It might then reset the token to NULL in the database. The key point is that it must be "impossible" (read: very hard) for anyone to guess what the token is even if they can see the hashed value in the table.

Cloud function authorization vs validationHandler

Found myself opening a couple of functions for access to users with invalid session tokens. The only way I could find to do that is to intercept the request using a bodyParser before Parse gets the request and removing sessionToken from the request.
Now trying to do a better job managing authorization to all functions - My question are:
can I relax the requirement that if a sessionToken is included it must be valid in any other way? Is session token validation done using a default validationHandler that can be replaced or is that done elsewhere?
to control access to cloud functions, is there anything like ACL roles? does cloud function's "validationHandler" accept only param? or can I inspect the user object as well?
Yes. In parse-server you can make sure that the sessions are valid because if you will try to run any CRUD operation with invalid session you will get http 403 error that your session is not valid or expired. You can control on the "Length" of your session by changing the sessionLength property in your parse-server app. The default is 1 year
There is no control access to cloud functions but you can check if a logged in user trigger this function by checking if the request.user is not undefined. Cloud functions can get only params in key-value pairs and those params cannot be Parse Objects. if you want to send ParseObject you can send the objectId of the parse object and then query for it in cloud code to get the full object. You can always access the user context in request.user (only if cloud code was triggered by the user). If you still want to "protect" your cloud code you can check if the calling user have a Role by query the Role DB and check if the user is contained there.

How can I hide API secret key when sending AJAX requests?

I am about to start working on a project, which is basically a web interface for a mobile banking application. The API is ready, I only need to provide the frontend part of the web application. I was going to make it using Backbone/Angular/Ember, but started to worry about the security.
Particularly, the following. As a rule, every API request must contain a parameter method_code, which is calculated as hash of user token, method name and secret API key. If I put the logic of how this param is calculated into one of .js files, anyone could potentially access some sensitive data using tools like Postman or even browser console. How should I go about this issue? I could have a server-side script generating the method_code for me, but is it possible to make it accessible only to my web app's requests?
every API request must contain a parameter method_code, which is calculated as hash of user token, method name and secret API key
I could have a server-side script generating the method_code for me, but is it possible to make it accessible only to my web app's requests?
Yes, the server-side script would be the way to go if you do not want to expose the secret API key within your client side code or request data.
User token can (presumably) come from the user's session cookie value? So simply have a server side method that takes the method name and then returns the method_code calculated from the secret API key (kept server side only) and the user token.
The Same Origin Policy will prevent another domain making a request to your API and retreiving the method_code. I'm also assuming the API and front-end code runs on the same domain here, although if this is not the case you can use CORS to allow your front-end code to read and retreive data client-side via the API.
You can try to generate a token based on security factors and encrypt that and use it in your requests to identify your clients and valid requests.

Resources