A backend service needs to know the user for the service call. Reading through the API 1.6.0 documentation I have configured it to generate JWT and removed and republished my services as stated. Running tests, I am not seeing the JWT being passed to the backed service in the response headers in Fiddler. I am not using the ESB or Identity services from WSO2.
What am I missing?
JWT information should be passed in the header under the parameter X-JWT-Assertion. The Content is been encoded. Use TCPMon to intercept the request and see if the API Manager is actually passing the JWT. This would be a good starting point to debug.
Related
I have a requirement that I need to validate 3rd party Authorization Server access token in wso2 API manager. If token active and valid then allow resource
imho as the simplest solution you could build a custom inbound mediation flow for that (if you are familiar with wso2 esb mediations). For this option you will loose some apim capabilities (throttling, authorization, analytics)
you should aware the default authorization handler would clean the Authorization header (as far I know) , so you may need to add a custom handler to preserve the original header value
Is there a way to authenticate the Microsoft or google OAuth token in active directory without using an authentication server?
Here is the scenario:
A client app gets an Microsoft access_token from some external service.
Client app will make a call to some secured web API and pass that access_token along with the request header
If the access_token passed by client is valid then API will provide response to the client.
Is there a way to validate that access_token on API side?
My normal understanding about OAuth 2.0 is there needs to be an authentication server to which both the client and API would talk to as shown in the figure below:
But if the token is provided by some external service, Can we use it to validate our web API. Are there any ways to implement such authentication?
You can learn more about AAD Signing Keys and handling Key Rollover using this page: Signing key rollover in Azure Active Directory
Validation of the token, once you have the signing key, can be done using existing libraries like OWIN. You can also try following instructions like this (although it seems the document isn't 100% complete yet): Manually validating a JWT access token in a web API
This library is also available, but I think OWIN is supposed to have replaced it in general.
Also check out this blog post, which has a pretty great deep dive into token validation.
I need to pass Authorization Header from API Manager (WSO2) to my Service Bus Aplication (Oracle).
I saw in another post that I cant do that, because API will validate the token against the key manager and drop that token before calling the back end. (How to pass authorization header in WSO2 OAuth2 and its backend API server Oauth2?)
There's any alternative to pass the token from API Manager to my service bus application?
There's some additional settings for that?
In conf/api-manager.xml, change value of "RemoveOAuthHeadersFromOutMessage" to false. Authorization header will not be removed and you can access it in your sequence, then you can set it to the request header to you backend. Not sure whether this is what you want or not.
One option would be to send same oauth token in another custom header and then by adding a custom mediation sequence in the api manager, set that custom header to Authorization header and then send it to backend server.
https://docs.wso2.com/display/AM1100/Pass+a+Custom+Authorization+Token+to+the+Backend.
I'm researching WSO2 API Manager and I discover that if I use WSO2 API Publisher and API Store, I would meet XSS and CSRF security errors. With XSS, I see that WSO2 didn't encode HTML character input. With CSRF, I see that WSO2 didn't create token when I request from client to server and vise versa.
Does everyone know how to config WSO2 to prevent these security error or how to fix them.
Thanks in advanced.
On our side, there are a few things we do when publishing/consuming APIs via the API Publisher and API Store:
Set the Transports property to just HTTPS so that we can limit API availability to just HTTPS.
For each HTTP method, we set the Auth Type to either Application, Application User or both, but never none. This will force the client to utilize the WSO2 Access Token scheme to invoke the APIs hosted on the API Store.
On the client side, we have been invoking the Token API to generate and renew user and application access token so that we don't have to manually re-generate keys in the API Store.
Utilize API in-sequence to escape special characters.
We fix these type of security issues in our next release AM V 1.7.1. You can expect it in 3rd week of September.
I have an application that uses Basic Authentication to authenticate and authorize service calls. I am setting up our WSO2 API Manager on a separate server but are unsure how to pass the base64 encryption from the API Manager through to my application to authorize certain service calls.
This information is not readily available in the documentation so I am not sure it is even supported.
Has anyone used this or knows how to achieve this?
If you want to provide your own authentication mechanism you can do this very easily by implementing the org.wso2.carbon.apimgt.gateway.handlers.security.Authenticator and set it in authentication handlers chain.
You can refer the org.wso2.carbon.apimgt.gateway.handlers.security.oauth.OAuthAuthenticator for reference.
You can provide the credentials when you create an API at publisher. You can check the WSO2 documentation about adding an API. At publisher for "Endpoint Type" you have to select Secured and then need to provide username/password.
Authentication occurs in API Manager via the APIAuthenticationHandler, which is among the handlers defined in your API sequence definition (/repository/deployment/server/synapse-configs/default/api). To disable authentication for that particular API (since API Manager handles basic authentication itself), just remove or comment out the handler. Users should then provide the basic authentication required by the back-end service rather than the API Manager token, since they will no longer need it.