I need to add a WebRootContext to all the calls in the WSO2 Identity Server's Implicit Flow so that I can make calls through an API Gateway. I have managed to do this for all the calls I need by changing the
<WebContextRoot>/wso2-is<WebContextRoot>
property as well as changing the name of my webapp folders: wso2-is#authenticationendpoint and wso2-is#oauth2 endpoints. I can now successfully call http://localhost:9443/wso2-is/oauth2/authorize.
I also changed the endpoints in repository/conf/identity/identity.xml to include the wso2-is root context, specifically the OAuth2AuthzEPUrl, so that in the management console this shows up under identity:
However, after I login, the application calls http://localhost:9443/wso2-is/commonauth which has a return location of http://localhost:9443/oauth2/authorize?sessionDataKey=... and I can't figure out how to add my context root to the returning call. Where does the commonauth endpoint get the location it returns to? I'm assuming there is some property I need to set to make that happen, but I can't find it.
I also tried re-seeding the database with all my changes and this did not solve my issue either.
I looked in the source code here in github and couldn't find any references to commonauth or oauth2/authorize that stood out as to where this call is being formed. Any additional details would be greatly appreciated.
As per the official documentation, using a reverse proxy is the recommended way to add a custom context path to wso2 products.
However, as I wrote in another question, I could complete the implicit flow with local auth successfully with the mentioned configs in my answer.
I guess, what you are missing here is ProxyContextPath.
Related
I am trying to set up WSO2 Identity Server behind a reverse proxy for SSL offloading. For example, let's say if WSO2 IS is available at say https://<some-ip>:9443/, I am trying to put it behind reverse proxy with address such as https://<domain name>/is/. Note the context path /is and SSL port 443. I thought that this will be trivial enough but sadly I am unable to find any conclusive documentation for achieving the same.
My applications are using OIDC to connect to WSO2 IS and using Azure Application Gateway as reverse proxy - typically all API calls works well but neither of UI (or flows involving redirections) works due to context. I can also fix redirects by URL rewriting at reverse proxy but that still doesn't solve problems. For example, login page will appear but XHR call from the same will go to /logincontext instead of /is/logincontext. Where can I set up the proxy context path in WSO2 IS? I already tried setting the same in .toml file (equivalent of setting it in carbon.xml) but it seems to be affecting only Management Portal.
WSo2 IS documentation talks about setting it up behind ngnix but that documentation is not using any path context. I could find reverse proxy documentation for other WSO2 product such as WSO2 API Manager but it only involves updating carbon.xml and that doesn't work for WSO2 IS. I am not a java person and hence, finding it difficult to figure out web app organization of WSO2.
Any help/link to documentation/guide to set up with proxy context will be useful.
I know that this answer comes a little bit late but recently I had a similar issue and here it is how I made it work, maybe it could be helpful for someone. I was using WSO2 IS 5.11.0.
Note:
I checked similar questions on stackoverflow and found a few but none was enough by itself for my case.
Maybe the solution I came up with is not the best or the most correct but it is the only one I could make work.
Here's how I did, assuming the context path is is:
Open Carbon Management Console and go to Identity Providers -> Resident. Then, go to Inbound Authentication Configuration -> OAuth2/OpenID Connect Configuration. Here, change the hostname under Identity Provider Entity ID to https://domain_name:443/is/<remaining path>.
Make sure that the port number is present or absent both here and in the client application. If there is a mismatch between the two, for some reason, it won't work (or at least it didn't for me).
Open the file deployment.toml and modify it as follows:
under the [server] section, add your proxy context at the end of the base_path url, e.g. base_path = "https://$ref{server.hostname}:${carbon.management.port}/is";
of course, also add proxy_context_path = "is" (actually, this last line should be enough but for some reason in my case it wasn't, so I had to modify the base path too);
under [transport.https.properties] add proxyPort="443".
For the record, I also turned off compression, by adding:
[transport.http.properties]
compression="off"
[transport.https.properties]
...
compression="off"
and set the token issuer URL equal to the entity id set up in Carbon, with:
[oauth]
use_entityid_as_issuer_in_oidc_discovery = true
but found out that these last two steps (turning off compression and setting the entity id as issuer) weren't needed.
Disable the csrf guard by setting org.owasp.csrfguard.Enabled = false
in the file /repository/resources/conf/templates/repository/conf/security/Owasp.CsrfGuard.Carbon.properties.j2.
This step was necessary for me to avoid the 403 Error after logging in on the Carbon Console (turning off compression didn't work).
Lastly, if you use nginx as reverse proxy (as I did), add these two lines in the location used for wso2:
proxy_redirect https://domain_name/oauth2/ https://domain_name/is/oauth2/;
proxy_redirect https://domain_name/carbon/ https://domain_name/is/carbon/;
These are needed (or at least were for me) because some URLs are not under the context path. In particular, the last one allows you to open the Carbon Console at https://domain_name/is/carbon/.
References:
wso2 api manger carbon page gives 403 Forbidden
WSO2 Identity Server login returns a 403
WSO2 Identity Server port configuration
To understand the template-based configuration model adopted from version 5.9.0 onwards, see:
https://apim.docs.wso2.com/en/latest/reference/understanding-the-new-configuration-model/
https://mcvidanagama.medium.com/understand-wso2-api-managers-new-configuration-model-6425a2710faa
Here are some useful configuration mappings from the old xml to the new toml based model:
https://github.com/ayshsandu/samples/tree/master/config-mapping
We have a strange situation. It's a web service (svc1) that calls another web service (svc2) on a different box, both in websphere. Works in every previous environment.
But recently they built out another staging environment as largely a clone of a working one. The service is failing with this message everytime svc1 attempts to call svc2.
Caused by: org.apache.axis2.AxisFault: The system cannot infer the transport information from the [svc2's URL] URL.
at org.apache.axis2.description.ClientUtils.inferOutTransport(ClientUtils.java:81)
at org.apache.axis2.client.OperationClient.prepareMessageContext(OperationClient.java:304)
at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:180)
at org.apache.axis2.client.OperationClient.execute(OperationClient.java:165)
at org.apache.axis2.jaxws.core.controller.impl.AxisInvocationController.execute(AxisInvocationController.java:578)
at org.apache.axis2.jaxws.core.controller.impl.AxisInvocationController.doInvoke(AxisInvocationController.java:127)
at org.apache.axis2.jaxws.core.controller.impl.InvocationControllerImpl.invoke(InvocationControllerImpl.java:93)
at org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler.invokeSEIMethod(JAXWSProxyHandler.java:419)
... 45 more
The URL is correct. We can point the not-working apps at a database supporting a working set of apps and it works, but when we point the working apps from that other environment at the not-working environment's DB, it stops working.
This seems to indict the DB, yet the error has nothing to do with the DB. Svc1's only DB call BEFORE the call to svc2 happens well before the service call and works fine according to logs. The logs indicate svc2 never gets the request. So how can database be the problem?
I know this isn't alot to go on, but does anyone even have suggestions on where to look to narrow this down? I can't believe the DB is the problem based on the code and when it's failing...yet the DB swapping test seems to imply it is.
I might be pointing out the obvious, but the error message is telling you one of two things: either svc1 isn't configured correctly to invoke svc2, or svc2 isn't up and running.
For clarity, if I label the working environment: enviornmentA and the not-working environment: environmentB.
Based on what you said, you were able to use environmentB.svc1 to invoke environmentA.svc2? If that is true, than environmentB.svc1 is configured correctly and working. Which leaves svc2. You said svc2 doesn't receive the request, which means its up at least. Well, like you'd mention this isn't much to go on but I'd make sure you configured svc2 correctly, since it is up. Configuring a Web Service can be complicated, but one of the things that can be configured is making a Web Service available to client invocation. So you might want to check out this link for information on how to configure it:
https://www.ibm.com/support/knowledgecenter/SSAW57_9.0.0/com.ibm.websphere.nd.multiplatform.doc/ae/twbs_publishwsdl.html.
There are a bunch of similar articles on configuring your Web Service that might help you to solve what's missing, so I would verify that the configuration for enviornmentB.svc2 matches enviornmentA.svc2 since you know that one is working.
I'm running WSO2 5.7.0, using OIDC with the Implicit Flow. I have set the context root to wso2-is, so the authorize endpoint is located at http://MY_DOMAIN/wso2-is/oauth2/authorize. When I begin the flow with a GET call to the oauth2/authorizeendpoint, I am redirected to http://MY_DOMAIN/authenticationendpoint/login.do?client_id=MY_CLIENT_ID&commonAuthCallerPath=%2Foauth2%2Fauthorize....
The problem is that it drops the context root and so later in the Implicit Flow I am (incorrectly) redirected to http://MY_DOMAIN/oauth2/authorize, which fails because that URL lacks the context root of wso2-is. How/where in the code is the commonAuthCallerPath parameter set?
As per the official documentation, using a reverse proxy is the recommended way to add a custom context path to wso2 products.
If you are not going to use a reverse proxy, I would suggest the following steps to add a custom context path. But, note that I have tested basic authentication with oauth2/oidc only.
Set WebContextRoot in repository/conf/carbon.xml to /wso2-is to change the context path of the carbon management console
Set ProxyContextPath in repository/conf/carbon.xml to /wso2-is
Rename oauth2.war and authenticationendpoint.war in repository/deployment/server/webapps/ by adding a prefix wso2-is#
Update repository/conf/indeitiy/identity.xml all the relevent instances of the following pattern by adding the context path /wso2-is after the port
${carbon.protocol}://${carbon.host}:${carbon.management.port}/xxxxx
to
${carbon.protocol}://${carbon.host}:${carbon.management.port}/wso2-is/xxxxx
Update AuthenticationEndpointURL, AuthenticationEndpointRetryURL and AuthenticationEndpointMissingClaimsURL values in repository/conf/identity/application-authentication.xml by adding /wso2-is prefix
Restart the Identity Server
Do not forget that, this is not the recommended way in the documentation.
I am trying to implement a partner link with a dynamically determined endpoint address in a WSO2 BPS BPEL process. The idea is that the request sent to the process contains an endpoint URL and that this URL is used as the address for a certain partner link. I have successfully used endpoint references stored in the registry before, but I can't use that approach here as the address can be different every time the process is called.
I have tried a number of different approaches (using WSO2 BPS 3.5.1 and WS02 Developer Studio 3.8.0):
The approach used in the DynPartner example referenced in https://stackoverflow.com/questions/11092515/dynamic-partner-links-and-dynamic-addressing-with-ode-bpel. This gives me the following validation error in Developer Studio: The from-spec of "<xs:simpleType "string">" is not compatible with to-spec of "<wsdl:portType
"DynResponderPortType">". Also, when I deploy and invoke the process, I get an error stating that the endpoint cannot be created (Couldnt create any endpoint for element ...)
Assigning a fixed value to the partner link, e.g. like this:
<wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsdl11="http://schemas.xmlsoap.org/wsdl/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.w3schools.com uep_schema.xsd">
<wsa:Address>http://localhost:8281/services/serviceaddress</wsa:Address>
</wsa:EndpointReference>
This works and does not give a validation error, but I haven't found a way to dynamically change the address that is used here based on the input my process is called with.
Create a variable that holds the endpoint reference, using a type that defines the content of an endpoint reference. I've tried several XSDs (http://docs.oasis-open.org/wsbpel/2.0/OS/serviceref/ws-bpel_serviceref.xsd, http://svn.wso2.org/repos/wso2/carbon/platform/branches/turing/components/unified-endpoint/org.wso2.carbon.unifiedendpoint.core/4.2.0/src/main/resources/schema/uep_schema.xsd (which doesn't get validated without errors), the ws-addr.xsd from w3c, my own very simple XSD). I've had varying success with regarding how well Developer Studio could handle them and for instance generate initializations, but they all share the problem that I get a validation error stating something like The from-spec of "<element "EndpointReference">" is not compatible with to-spec of "<wsdl:portType
"ThisIsThePartnerLinkPortType">" -.
At this point, I am using the last approach with my own simple XSD. The process is actually working the way I intend it to, but I am still getting validation errors in Developer Studio which I would like to get rid of. Is there another and better way to approach this?
Thanks in advance for your help.
For anyone who is having the same issue: The approach is use now is that the BPS calls a specific proxy in the ESB (at a fixed location) and provides the endpoint URL to that proxy. The proxy then performs the actual call to the endpoint.
This has a number of advantages for me:
I get rid of the validation errors in the BPEL designer
Passing through the ESB allows me to perform validation on the message that I receive from the service located at the dynamic URL. Note that this is not possible in the BPS at the moment, as validation is not yet properly implemented. See also https://docs.wso2.com/display/BPS351/WS-BPEL+2.0+Specification+Compliance
I am trying to setup a simple API test against a local endpoint. I have create the sample API (phone number lookup) and that works fine.
http://192.168.1.11:8080/api/simpleTest is my endpoint and the WSO2 service also runs on 192.168.1.11 ... but when I test it in 'publisher', it always fails. This is a simple GET with no parameters.
I can run it from a browser or CURL (outside of WSO2) and it works fine.
Thanks.
I assume you talk about clicking the Test button when providing Backend Endpoint in API publisher.
The way that Test button works at the moment (as far as I understand) is that it invokes HTTP HEAD method on the endpoint provided (because according to RFC 2616, "This method is often used for testing hypertext links for validity, accessibility, and recent modification.")
Then it checks response. If response is valid or 405 (method not allowed), then the URL is marked as Valid.
Thus sometimes, if backend is not properly following RFC, you might get otherwise working URLs declared as Invalid during the test because of that improper HEAD response evaluation. Obviously, this is just a check for your convenience and you can ignore the check if you know the endpoint works for the methods and resources you need it to work.
P.S. Checked it on API Cloud but behavior is identical to downloadable API Manager.