I'm trying to create some SSRS reports that will get data from our web api.
I understand how you can set up a datasource from a particular endpoint of a web service, however connection to our api requires header values being added to the request such as the bearer token for authentication and some other values that we use along with the content type that I need back from the api.
I don't know how or if you can make changes to the request header to allow successful connection to use this as a datasource. I've come up empty from extensive googling!
Does anyone know how to do this or any articles that describe how to do this?
I think that solution for you is to implement your own data-processing extension, which will be able to connect to your web service endpoint and provide required headers.
See more info on MSDN.
Related
I wrote a sample ballerina code in choreo API to return x-jwt-header header value to the caller.
when I turn off the security for that API, the header value is not there in the request headers. Does it mean the API is unsecured?
I want to crate an unsecured API. I want to know whether the header values will be there or not?
When you disable the security, basically API is exposed without security to the consumers. Hence the API is unsecured. x-jwt-header is used to pass the enduser data to the backend services. If you don't provide an access token when invoking API, then it can't send the enduser information to the backend services. That's why you are getting the response without that header.
I'm attempting to add a REST data source from Xero.com to my app on apex.oracle.com. I've confirmed my credentials work properly when connecting to Xero's Oauth2 api from elsewhere, but I can't connect from the REST data source wizard. I suspect this is because the authorized redirect URI I am providing to Xero is incorrect. I have been providing the URL "https://apexea.oracle.com/pls/apex/apex_authentication.callback" as recommended by this guide.
Is there another callback URL I should be using, or, if not, another method then the REST data source wizard by which to connect?
Out of the box, REST Data Sources only support the OAuth2 "Client Credentials" flow, which does not involve any browser redirects.
For redirect-based OAuth flows like "Implicit Grant" or "Authorization Code", there is no declarative access; so you would need to implement custom PL/SQL code in order to get the token. Also the callback endpoint would beed to be provided by you, e.g. as a REST service or an "AJAX Callback".
I have a Lambda function which triggered by API Gateway service, however this API is accessed by front-end application, this application not requiring the users to login or sign up to use it.
However I would like to secure my API to allow only from my front-end application.
After my research I found that I can use custom authorization in API Gateway, this custom authorization will check the authorization header of the incoming request and validate it.
the question is, can I use Amazon Cognito for something like this(implicit grant type)?
if not what is the thing that the front-end application will send to me to be validated and how can I keep it always changeable, so no one can guess it?
Thank You.
You could check the headers, but if they're always the same, someone can send an HTTP request with those headers - from any client - and trick your Lambda into thinking it's coming from your UI.
Even if you generate a unique token every time your UI is loaded and include it in the headers, someone could take that token and send requests from another client as well.
You could build fancy JavaScript tricks to make headers more dynamic, but it would only make it harder to use your API from another client, not impossible.
I'm trying to call an Azure API App configured with Azure AD authentication. Assume for the purposes of this question I cannot use the Azure SDK and need to write code to get a token and insert it into the API request.*
I have established that there are two modes - 'client flow' and 'server flow', where client flow entails following at least one redirect to an issuer to get a token, and server flow where the server does this for you. Since I'm talking about doing this in code, following redirects would be possible but fiddly, so I'd prefer to use a mode where the URI or URIs to visit are known ahead of time and return content, rather than redirecting. The following diagram illustrates how the gateway routes all requests.
I think the mode I need is client flow, which would go something like:
Get an access token from the identity provider (which is what? how do I find out where this resides? what is the format of the request I have to send to the IdP?)
Pass the access token to the gateway (in what format?)
Receive another token in the gateway response
Supply this token in a header when making an API request (which header?)
How am I supposed to do this? The Azure documentation doesn't give enough detail about how it works, and expects all users to just use the SDK, which hides what is actually happening.
The actual reason is that ultimately this will need to be called from BizTalk, which uses the WCF WebHttpBinding to call restful services. I'm writing a custom behaviour to insert a token header into the request, but I need to know how this token should be acquired. It's possible to run arbitrary code in BizTalk but trying to do this makes the solution complicated, and config-only or mostly-config with minimal, loosely-coupled code is the simpler solution
Just want to understand your scenario better, Because you are going to use it from BizTalk Receive Pipeline, The scenario can be simplified by enabling a customer authentication token right ? Basic username and password for your API you have hosted on the cloud. Does BizTalk want to authenticate it self with tokens for each AD User ?
To answer some of your questions
Get an access token from the identity provider (which is what? how do I find out where this resides? what is the format of the request I have to send to the IdP?)
After you have configured your AD configuration, Once you have completed the authentication, I am assuming your are using ASP.Net here, You can find everything you need about the claims on your Thread.CurrentPrincipal, You can convert it to ClaimsPrincipal like so var claimsPrincipal = Thread.CurrentPrincipal as ClaimsPrincipal; and then you will find a lot of good information on this object. Name of the user logged in, list of claims the principal has etc. I have not explored every avenue here, but this should be a good starting point.
Your API App is running on this process which means you have access to these claims in your API App code as well.
I would build a custom pipeline in BizTalk that uses Azure SDK to authenciate and build this scenario, it is a bit complicated but it will give you more control over what goes through the pipeline as well when authentication fails with permission issues and so on.
I have a web service built with WebAPI that accepts JSON requests and responds accordingly. The core architecture is built but there isn't any authentication/authorization.
After a lot of googling and poking around sample projects, I'm not sure where to start. I've found a ton of material from 2008 and 2009 but not a whole lot of recent guides/workflows for WebAPI / single page apps. I think the workflow should be as follows:
Check to see if the user is logged in: How can this be done with javascript? Do I send a cookie to my webAPI? If so, do I send that cookie as a parameter in the body of the request?
Let the user log in / register: How is this data encrypted/decrypted? Surely I can't be sending passwords over the wire... is this where SSL comes in?
Provide them with access to what they have rights to access: I think I got this - I can just authorize in the controllers on a per-request basis.
Any info would be awesome.
Basically you need a token based authentication or authorization.
If you are referring to the ASP.NET WebAPI, the following project will be a great place to start:
http://thinktecture.github.com/Thinktecture.IdentityModel.45/
Even if you are not using ASP.NET WebAPI, the following video is a great introduction on how to provide authentication/authorization on RESTful web services:
http://vimeo.com/43603474
To answer some of your questions:
Check to see if the user is logged in: How can this be done with javascript? Do I send a cookie to my webAPI? If so, do I send that cookie as a parameter in the body of the request?
You can use a cookie but I normally use the header in order to avoid common XSRF attacks. Cookies are automatically included whenever a http request is sent from the browser.
is this where SSL comes in?
Yes. If you are going to go ahead with the token based approach, you can use a separate server (Identity Server) to do the authentication for you.
JavaScript clients are unique. Do you have the Web API and the page serving up JavaScript in the same domain? If not, you have same origin policy restrictions. If you have the same Web application hosting the web pages and Web API, you can use forms Authn. In that case, you don't need to send the cookie containing the authentication ticket yourself from JavaScript. Browsers do that for you and that is the cause of XSRF problem. You have to be careful about JavaScript sending credentials that the end user is not supposed to know. If JavaScript knows something, any intelligent end user can get to that knowledge. OAuth 2.0 implicit grant could be a good choice. The end user enters the credentials (password) in the authorization server which issues an access token. JavaScript gets the token and presents it to the web API but it will never have access to the credentials.