how use wso2 OAuth mediator in micro integrator 4.1 - oauth

I can not figure out how to use the wso2 OAuth mediator. I use the wso2 micro integrator 4.1, identity server 5.11, and wso2 IntegrationStudio 8.1.
Is this true: OAuth mediator gets an access token and sends it to the identity server and gets the answer if the access token is valid or not?
We should add an OAuth mediator at the beginning of an inSequence?
What should come after the OAuth mediator?
What does the curl message look like when using the OAuth mediator?
I have an API like this (without an OAuth mediator):
<api context="/user-service3" name="Soap2Rest" xmlns="http://ws.apache.org/ns/synapse">
<resource methods="POST">
<inSequence>
<send>
<endpoint>
<http method="post" uri-template="http://localhost:9090/user-service" />
</endpoint>
</send>
</inSequence>
<outSequence>
<send/>
</outSequence>
<faultSequence>
<send/>
</faultSequence>
</resource>
I send a curl message like this:
curl -X 'POST' -k 'https://localhost:8253/user-service3' \
-H 'Content-Type: application/soap+xml' \
-H 'accept: */*' \
-d '
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:user="http://user.ws.xx.com/">
<soap:Header/>
<soap:Body>
<user:createUser>
<arg0>abc</arg0>
</user:createUser>
</soap:Body>
</soap:Envelope>'
what should I change in the curl command after adding the OAuth mediator at the beginning of the inSequence?
<oauthService remoteServiceUrl="https://testdomain.org:9444/services/" username="admin" password="admin"/> -->
I tried different ways but get errors from the wso2 identity server.
I add the Authorization header to curl.
-H 'Authorization : Bearer 8aa447a9-b929-355c-a885-1b92c5266051' \
But Micro Integrator shows this log:
INFO {LogMediator} - Direction: request, MESSAGE = Executing default 'fault' sequence,
ERROR_CODE = 0, ERROR_MESSAGE = Error occured while validating oauth 2.0 access token,
Envelope:
<?xml version='1.0' encoding='utf-8'?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:user="http://user.ws.xx.com/">
<soap:Body>
<user:createUser>
<arg0>abc</arg0>
</user:createUser>
</soap:Body></soap:Envelope>

Yes
It can be anywhere
Anything
Add the Authorization header to curl.
The curl command is correct. Based on this answer I found out some of the wso2 product's org.wso2.carbon.identity.oauth.stub jar files are not compatible with each other. I thought maybe my problem is that.
I copied the org.wso2.carbon.identity.oauth.stub_6.4.111.jar file from the WSO2 Identity Server to the wso2/components/plugins directory of the WSO2 micro integrator.
cp wso2is-5.11.0/repository/components/plugins/org.wso2.carbon.identity.oauth.stub_6.4.111.jar wso2mi-4.1.0/wso2/components/plugins
Then updated the bundles.info file of the micro integrator:
vi wso2mi-4.1.0/wso2/components/micro-integrator-default/configuration/org.eclipse.equinox.simpleconfigurator/bundles.info
modified this line:
org.wso2.carbon.identity.oauth.stub,6.1.0,../plugins/org.wso2.carbon.identity.oauth.stub_6.1.0.jar,4,true
to this:
org.wso2.carbon.identity.oauth.stub,6.4.111,../plugins/org.wso2.carbon.identity.oauth.stub_6.4.111.jar,4,true
After restarting the micro integrator server, my curl command works fine.

Related

Jenkins - No valid crumb was included in request

Jenkins - 2.263.1(LTS) deployed through tomcat on CentOS-8.2and have Nginx reverse proxy running in-front of Jenkins.
Under Manage Jenkins > Configure Systems - Apply and Save not working, Due to this error, i cannot Apply (or) Save any of my configurations, It always shows below error on browser (Firefox & Chrome).
HTTP Status 403 – Forbidden
Type Status Report
Message No valid crumb was included in the request
Description The server understood the request but refuses to authorize
it. Apache Tomcat/9.0.30
Also Jenkins > Manage Jenkins > Configure Global Security - Apply works. But Save not working this too results same above given error.
Systems log error message.
Feb 19, 2021 10:56:05 AM WARNING hudson.security.csrf.CrumbFilter
doFilter No valid crumb was included in request for
/jenkins/configSubmit by ankit.sahu. Returning 403.
Workaround tried:-
1) Under Configure Global security > CSRF Protection > Enable proxy compatibility( Tick marked Enabled). - Didn't work so disabled with below command.
2) hudson.security.csrf.GlobalCrumbIssuerConfiguration.DISABLE_CSRF_PROTECTION = true - Even this didn't solve the problem.
3) Installed the Strict Crumb Issuer plugin.
Enabled this plugin and unchecked Check the session ID from its configuration (Under Jenkins Configure Global Security).
4) Restated the Jenkins.
Even tried by adding below in /apache-tomcat-9.0.30/conf/tomcat-users.xml file.
<?xml version='1.0' encoding='utf-8'?>
<tomcat-users>
<role rolename="manager-gui"/>
<role rolename="manager-script"/>
<role rolename="manager-jmx"/>
<role rolename="manager-status"/>
<role rolename="admin-gui"/>
<role rolename="admin-script"/>
<user username="user" password="password" roles="manager-gui,manager-script,manager-jmx,manager-status,admin-gui,admin-script"/>
</tomcat-users>
However still experiencing same problem. I don't know how to fix it, Can someone help me?
You can (temporarily) disable CSRF with below groovy script. Go to Manage Jenkins >> Script Console, then execute the below groovy script.
import jenkins.model.Jenkins
def instance = Jenkins.instance
instance.setCrumbIssuer(null)
The nonces embedded into web output from Jenkins with CSRF protection are based (at least in part as I've read) on values from the requesting client. In addition to making sure your reverse proxy is correctly configured to pass X-Forwarded-For and X-Forwarded-Proto, make sure that Tomcat valve is in place to expose those header values in the servlet request API so Jenkins has access to them.
Add the following to $CATALINA_BASE/conf/server.xml, subordinate to the <Host> element:
<Valve className="org.apache.catalina.valves.RemoteIpValve" remoteIpHeader="x-forwarded-for" protocolHeader="x-forwarded-proto" />
ref: https://www.jenkins.io/doc/book/system-administration/reverse-proxy-configuration-troubleshooting/
ref: https://www.jenkins.io/doc/book/system-administration/reverse-proxy-configuration-with-jenkins/
ref: https://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Remote_IP_Valve
If you're using jenkinsapi, I resolved this error by specifying useCrumb=True in the constructor:
j = Jenkins(base_url, username=username, password=password, useCrumb=True)

Wildfly 10 JBossWS SOAP address rewrite for wsdl-uri-scheme=https for nested XML schema documents (XSD) referenced by the WSDL behind reverse proxy

NOTE: Cross post from developer.jboss.org
We have Wildfly 10 configured behind NGINX as a reverse proxy for handling the SSL requirements of the web service. Wildfly serves everything as plain HTTP and NGINX handles the HTTPS side of the request.
We have enabled the uri rewriting inside JBossWS with the following settings in standalone.xml
<subsystem xmlns="urn:jboss:domain:webservices:2.0">
<modify-wsdl-address>true</modify-wsdl-address>
<wsdl-host>jbossws.undefined.host</wsdl-host>
<wsdl-secure-port>8081</wsdl-secure-port>
<wsdl-uri-scheme>https</wsdl-uri-scheme>
The endpoint also uses a custom deployment descriptor: jboss-webservices.xml
<jboss:port-component>
<jboss:ejb-name>ClaimWebServiceBean</jboss:ejb-name>
<jboss:port-component-name>ClaimWSPort</jboss:port-component-name>
<jboss:port-component-uri>Claim</jboss:port-component-uri>
<jboss:transport-guarantee>CONFIDENTIAL</jboss:transport-guarantee>
</jboss:port-component>
The URI rewriting for the SOAP address and the schema location of the XSD included in the WSDL works correctly
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:tns="http://example.systems/webservices/" xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
xmlns:ns1="http://example.co.za/claim/zmf" attributeFormDefault="unqualified" elementFormDefault="unqualified"
targetNamespace="http://example.systems/webservices/">
<xs:import namespace="http://example.co.za/claim/zmf" schemaLocation="https://dev.example.ws:8081/webservices/Claim?xsd=ZietoClaim_2_1.xsd"/>
<!-- xml omitted -->
<wsdl:service name="ClaimService">
<wsdl:port binding="tns:ClaimServiceSoapBinding" name="ClaimWSPort">
<soap12:address location="https://dev.example.ws:8081/webservices/Claim"/>
</wsdl:port>
</wsdl:service>
The XSD referenced inside the WSDL contains 2 more import statements to import 2 more XSD's. This is however where the problem starts. In the extract below you will notice that the schema location uses http and not https for the other 2 XSD's.
Using curl to download the XSD referenced above give this content, which shows the problem:
<?xml version='1.0' encoding='UTF-8'?>
<xsd:schema xmlns:zdt="http://example.co.za/claim/zmf/datatypes" xmlns:zcdt="http://example.co.za/common/datatypes"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://example.co.za/claim/zmf" elementFormDefault="qualified"
targetNamespace="http://example.co.za/claim/zmf">
<xsd:import namespace="http://example.co.za/claim/zmf/datatypes" schemaLocation="http://dev.example.ws:8081/webservices/Claim?xsd=zmf_dt_2_1.xsd"/>
<xsd:import namespace="http://example.co.za/common/datatypes" schemaLocation="http://dev.example.ws:8081/webservices/Claim?xsd=zdt_1_2.xsd"/>
Is there a way to configure JBossWS to rewrite the shema locations inside the first XSD as well to use https?

WebSphere Docker OAuth

I need to implement OAuth against an IBM WebSphere server. For that purpose I built a docker environment https://github.com/hhoechtl/websphere-oauth according to http://www.ibm.com/developerworks/websphere/techjournal/1305_odonnell2/1305_odonnell2.html
But if I try to get a token
curl -X POST -H "Accept-Charset: UTF-8" -H "Content-Type: application/x-www-form-urlencoded" -d 'grant_type=password&client_id=LibertyRocks&client_secret=AndMakesConfigurationEasy&username=admin&password=admin' "https://192.168.99.100:9443/oauth2/endpoint/DemoProvider/token"
I get the error
{
"error_description": "CWWKS1406E: The token request had an invalid client credential. The request URI was /oauth2/endpoint/DemoProvider/token.",
"error": "invalid_client"
}
But according to my server.xml that should be correct. What am I missing?
Would you be able to turn on and provide the server trace for that invocation? The message indicates that either credentials weren't found in the request, or credentials were found but were invalid for that client. It would be useful to know which is the case here.
You can enable trace by adding this snippet to your server.xml:
<logging traceSpecification="*=info=enabled:com.ibm.ws.security.*=all=enabled:com.ibm.oauth.*=all=enabled" />
The next day it just worked, no idea why.

Consuming Web Service using 2 Way SSL using Orbeon client code

We are trying to consume web service from orbeon client code. Everything works fine with one way SSL however we now wish to call the web service using 2 way SSL. We are able to call the web service using 2 way SSL successfully using the Apache CXF framework using Java code.
I followed the steps outlined in the Orbeon Wiki.
Changes made in properties-local.xml
<property as="xs:anyURI"
name="oxf.http.ssl.keystore.uri"
value="/apps/property/ClientStore.jks"/>
<property as="xs:string"
name="oxf.http.ssl.keystore.password"
value="password"/>
<property as="xs:anyURI"
name="oxf.url-rewriting.service.base-uri"
value="http://localhost:8085/Orbeon"/>
<property as="xs:anyURI"
name="oxf.fr.persistence.exist.uri"
value="http://localhost:8085/fr/service/exist"/>
<property as="xs:anyURI"
name="oxf.fr.persistence.exist.exist-uri"
value="http://localhost:8085/exist/rest/db/orbeon/fr"/>
After implementing the changes outlined above we are getting the exception below:
ERROR XFormsServer - xforms-submit-error - setting throwable {throwable:
"javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
at com.sun.net.ssl.internal.ssl.SSLSessionImpl.getPeerCertificates(Unknown Source)
at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128)
at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:390)
at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:488)
at org.apache.http.conn.scheme.SchemeSocketFactoryAdaptor.connectSocket(SchemeSocketFactoryAdaptor.java:62)
at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:148
Java start up options are:
-Djavax.net.ssl.trustStorePassword=password
-Djavax.net.ssl.keyStore=/apps/property/DMClientStore.jks
-Djavax.net.ssl.keyStorePassword=password
-Djavax.net.ssl.trustStore=/apps/property/trustkeystore.jks
Questions:
Are these properties sufficient for enabling 2 way SSL?
For Apache CXF we need to provide two keystores, one with the client certificate and a truststore. Where do we configure both of these keystores for Orbeon?

Spring Security SAML - Failed to verify signature

I'm using the Spring Security SAML 2.0 sample webapp on Tomcat 7 and have modified it to try to get it to authenticate against a Ping Identity service. The webapp is talking to the service and it's sending back an assertion, but it's failing when trying to verify the signature, as shown by the debug output below:
- Attempting to verify signature and establish trust using KeyInfo-derived credentials
- Signature contained no KeyInfo element, could not resolve verification credentials
- Failed to verify signature and/or establish trust using any KeyInfo-derived credentials
- Attempting to verify signature using trusted credentials
- Failed to verify signature using either KeyInfo-derived or directly trusted credentials
- Validation of received assertion failed, assertion will be skipped
org.opensaml.xml.validation.ValidationException: Signature is not trusted or invalid
I understand that it's not able to verify the signature, and I have been given a certificate by the Ping Identity admins to use, but I'm unsure of how to include it in the application. I've tried adding it to the JKS (keystore) that comes with the sample application using the JDK's keytool program, but it can't seem to find it in there. I've also tried adding it to the service provider's metadata xml file like this:
<md:KeyDescriptor use="signing">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>
[Certificate is here...]
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
However it still returns the same error.
Is there a specific place I should put the certificate in order to validate the signature? I'm relatively new to SAML and application security in general, so I apologise if I'm using the wrong terminology.
Finally got this to work. Turns out I'd missed out a line of configuration in the security context file, and that (it appears as though) no X509 certificate definition was needed in the service provider's metadata XML file.
Basically I'd already imported the public key I'd been provided with into the existing JKS (using keytool), but I hadn't told the application to specifically use this. In order to do this, I had to go into the security context file (in my case "securityContext.xml") and add the following line to the ExtendedMetadata bean definition for the SP's metadata xml file:
<property name="signingKey" value="[alias of the provided key in the JKS goes here]"/>
Hence after this modification, the ExtendedMetadataDelegate bean definition looked like this:
<bean class="org.springframework.security.saml.metadata.ExtendedMetadataDelegate">
<constructor-arg>
<bean class="org.opensaml.saml2.metadata.provider.FilesystemMetadataProvider">
<constructor-arg>
<value type="java.io.File">classpath:security/[Path to SP metadata xml file].xml</value>
</constructor-arg>
<property name="parserPool" ref="parserPool" />
</bean>
</constructor-arg>
<constructor-arg>
<bean class="org.springframework.security.saml.metadata.ExtendedMetadata">
<property name="alias" value="[SP alias goes here]" />
<property name="signingKey" value="[alias of the provided key in the JKS goes here]"/>
</bean>
</constructor-arg>
</bean>
Hope this helps anyone who might be in a similar situation.
In spring boot it can be configured in the assertingparty configuration
spring:
security:
saml2:
relyingparty:
registration:
yourrequestissuerid:
assertingparty:
verification:
credentials:
- certificate-location: "classpath:idp.crt"

Resources