I have question on wso2 EI 6.6.0 and preemptive/non-preemptive authentication. Can I check which incoming calls to wso2 use preemptive and nonpreemtive authentication in Synapse handler? Some systems don't send the HTTP authorization header on the first call and generate error logs in wso2. Is there an attribute in wso2 to determine what kind of authentication it is?
Thank you
In a non-preemptive scenario, the client sends a request without the Authorization header and the server responds to the client with a WWW_Authenticate header indicating that the server requires Authentication details. So the client will read this header and send another request with the required authentication headers.
To answer your question the only way the server can identify whether the request is a non-preemptive request is to check the existence of the Authorization header. So in your Authentication Handler you can check the existence of the Authorization header and respond the client accordingly. You can refer this Authorization Handler implementation where the non-preemptive scenario is handled.
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
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.
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.
The SAML2 request is sent to WSO2 Identity Server with HTTP-GET binding, but it still POSTs the response. Any idea to let WSO2IS respect the request?
[2014-03-06 17:52:25,961] DEBUG {org.wso2.carbon.identity.sso.saml.util.SAMLSSOUtil} - Request message <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="_73d5b9c1-d448-4076-9e9d-98767f1e2a2d" Version="2.0" IssueInstant="2014-03-06T17:52:21" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-GET" AssertionConsumerServiceURL="http://host.tld/java-saml/consume.jsp"><saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">http://host.tld/java-saml/</saml:Issuer><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified" AllowCreate="true"></samlp:NameIDPolicy><samlp:RequestedAuthnContext Comparison="exact"></samlp:RequestedAuthnContext><saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef></samlp:AuthnRequest>
results in firefox:
You are now redirected back to http://host.tld/java-saml/consume.jsp If the redirection fails, please click the post button.
Any idea to fix it? In the request or in WSO2IS do I need to configure?
Yes.. It must be the expected behavior, SAML response must be sent as POST from IDP to the SP. (can not use HTTP Redirect) It is defined in the specification. Please check the saml-profile spec. WSO2 identity Server may not support for Artifact binding, therefore it does HTTP POST.
The identity provider issues a <Response> message to be delivered by the user agent to the service provider. Either the HTTP POST, or HTTP Artifact binding can be used to transfer the message to the service provider through the user agent. The message may indicate an error, or will include (at least) an authentication assertion. The HTTP Redirect binding MUST NOT be used, as the response will typically exceed the URL length permitted by most user agents.
I guess, POST button and the page that you shown can be changed and modified.
I am using wso2 ESB to secure my service. service is available through wsdl, and this service is insecured. My scenario is as follows: A system expose some apis or services, and they are insecured. I want to create proxy services to these services. If client invokes the proxy service, ESB should first check if the request contains the session ID, if yes, client can invoke the backend service. if no, client is redirect to a log in page. I think ESB can do this by adding a session ID or user ID header to the request, but I am lack of docs. can someone help?
and I have read [1], and conclude ESB will meet my demand.
[1] http://www.ws02.net/library/knowledge-base/convert-http-basic-authentication-ws-security-username-token/
I think you are expecting a custom header field from user request. Since you are creating proxies with the associated WSDL, you can add SOAP Header requirement in your wsdl and associate that WSDL to the proxy (using publishWSDL option). So, when user send request to your proxy he might need to add that particular header.
Other routing logic you can handle within proxy configuration