I am using wso2 5.0.0
I have a keystore that is currently signing the tokens generated by IS and is also used for https, when we access the console at https://servername:9443
<Security>
<!--
KeyStore which will be used for encrypting/decrypting passwords
and other sensitive information.
-->
<KeyStore>
<!-- Keystore file location-->
<Location>${carbon.home}/repository/resources/security/samlwso2-internal.***.com.jks</Location>
<!-- Keystore type (JKS/PKCS12 etc.)-->
<Type>JKS</Type>
<!-- Keystore password-->
<Password>*******!</Password>
<!-- Private Key alias-->
<KeyAlias>samlwso2-internal.***.com</KeyAlias>
<!-- Private Key password-->
<KeyPassword>******!</KeyPassword>
</KeyStore>
...
</Security>
I have another c2wso2.***.com.jks that has the certificate that I would like to use for https. Any pointers on configuring this?
I tried updating the security->keystore node with the c2wso2.***.com.jks, at which point, it was using this cert for both https and signing the tokens. This is expected, but I am not seeing a way to use a different cert for each of these functions
Also tried updating /repository/conf/tomcat/catalina-server.xml file as mentioned in https://docs.wso2.com/display/MB211/Changing+Default+Keystores. I thought this would force it to use this cert for https, but did not have any impact.
Related
is there a way to create a new jks only for synapse secure vault(ciphsertool)?
I configured ciphertool like in this manual https://docs.wso2.com/display/EI660/Working+with+Passwords+in+the+ESB+profile or this https://www.chakray.com/wso2-esb-tutorial-how-to-programmatically-manage-secure-vault-passwords/
I didn't find how to set up another keystore for encryption only
thanks
Yes when encrypting/decrypting passwords the server will be using the following keystore configuration block in carbon.xml
<InternalKeyStore>
<Location>${carbon.home}/repository/resources/security/internal.jks</Location>
<Type>JKS</Type>
<Password>wso2carbon</Password>
<KeyAlias>wso2carbon</KeyAlias>
<KeyPassword>wso2carbon</KeyPassword>
</InternalKeyStore>
So you can create a new keystore and change the configuration here and then change the cipher tool's keystore configurations at secret-conf.properties to point to the newly created keystore. You can read more here.
When WSO2 Identity Server 5.7.0 is starting, I get the following info in the console output:
INFO {org.wso2.carbon.crypto.provider.internal.DefaultCryptoProviderComponent} - 'CryptoService.Secret' property has not been set. 'org.wso2.carbon.crypto.provider.SymmetricKeyInternalCryptoProvider' won't be registered as an internal crypto provider. Please set the secret if the provider needs to be registered.
This is the configuration I used in the /repository/conf/carbon.xml :
<!--
Configurations related to Carbon Crypto Service which is a crypto framework used inside Carbon products.
-->
<CryptoService>
<Enabled>true</Enabled>
<!-- The crypto provider which is used for internal data encryption and decryption -->
<InternalCryptoProviderClassName>org.wso2.carbon.crypto.provider.KeyStoreBasedInternalCryptoProvider</InternalCryptoProviderClassName>
<!--
The crypto provider which is used for the crypto needs which come when communicating with external parties.
e.g. Signing, Decrypting.
-->
<ExternalCryptoProviderClassName>org.wso2.carbon.core.encryption.KeyStoreBasedExternalCryptoProvider</ExternalCryptoProviderClassName>
<!--
The list of key resolvers which will be used based on the context when handling crypto with external parties.
e.g. Resolving the public key of an external entity.
-->
<KeyResolvers>
<KeyResolver className="org.wso2.carbon.crypto.defaultProvider.resolver.ContextIndependentKeyResolver" priority="-1"/>
</KeyResolvers>
</CryptoService>
<!--
The KeyStore which is used for encrypting/decrypting internal data.
This block is read by Carbon Crypto Service.
-->
<InternalKeyStore>
<!-- Keystore file location-->
<Location>${carbon.home}/repository/resources/security/internal.jks</Location>
<!-- Keystore type (JKS/PKCS12 etc.)-->
<Type>JKS</Type>
<!-- Keystore password-->
<!-- <Password svns:secretAlias="Carbon.Security.KeyStore.Password">password</Password> -->
<Password>wso2carbon</Password>
<Secret>wso2carbon</Secret>
<!-- Private Key alias-->
<KeyAlias>wso2carbon</KeyAlias>
<!-- Private Key password-->
<KeyPassword>wso2carbon</KeyPassword>
</InternalKeyStore>
How can I resolve this problem?
WSO2 API Manager 3.0.0+ or EI6.6.0+ where deployment.toml file is used:
[encryption]
key = "CryptoService.Secret"
This will add proper config to carbon.xml on start.
For more info about how new configuration works: deployment.toml configuration options
For older version applies configuration in carbon.xml .. add tag Secret to CryptoService tag:
<CryptoService>
..
<Secret>SECRET_KEY</Secret>
</CryptoService>
You can add an element with a value. This value will be used as the SymmetricKey
<CryptoService>
...
<Secret>SECRET_KEY</Secret>
</CryptoService>
Identity server 5.3.0. Recently patched. I've replaced the default keystore and keys with my own. Utilizing the ciphertool to remove plain text passwords from various config files. I've successfully replaced the database password inside of repository/conf/datasources files using the ciphertool. Restarted the IS successfully. Was moving on to the keystore values inside of the carbon.xml file and I keep getting the following error:
TID: [-1234] [] [2017-10-16 21:39:44,322] ERROR {org.wso2.carbon.core.deployment.DeploymentInterceptor} - Error while pdating wso2carbon-sts in STSDeploymentInterceptor
java.io.IOException: Keystore was tampered with, or password was incorrect
at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:780)
at sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:56)
at sun.security.provider.KeyStoreDelegator.engineLoad(KeyStoreDelegator.java:224)
at sun.security.provider.JavaKeyStore$DualFormatJKS.engineLoad(JavaKeyStore.java:70)
at java.security.KeyStore.load(KeyStore.java:1445)
...
Caused by: java.security.UnrecoverableKeyException: Password verification failed
at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:778)
... 53 more
I've confirmed the password is correct. I even re-replaced the ciphertool reference inside of carbon.xml with the clear text value and restart successfully, again. My only guess at this point is that ciphertool is not handling special characters correctly. My pass has an ampersand (#). Any help would be appreciated.
Update: Went through the effort of recreating a brand new key store and key with a simple password... no special characters. Same results. After running ciphertool.bat -Dconfigure my carbon.xml entries looks good (see below). Which indicates the Xpath in cipher-tool.properties is correct. And I've triple checked the password in cipher-text.properties.
<KeyStore>
<!-- Keystore file location-->
<Location>${carbon.home}/repository/resources/security/KeyStore.jks</Location>
<!-- Keystore type (JKS/PKCS12 etc.)-->
<Type>JKS</Type>
<!-- Keystore password-->
<Password svns:secretAlias="Conf.Carbon.KeyStore.Password">password</Password>
<!-- Private Key alias-->
<KeyAlias>QaCert</KeyAlias>
<!-- Private Key password-->
<KeyPassword svns:secretAlias="Conf.Carbon.KeyPassword">password</KeyPassword>
</KeyStore>
John, I would submit this bug to WSO2's GitHub or JIRA instance:
On a side note, I noticed WSO2's use of encrypted passwords has an issue with special characters. This could be a general problem if WSO2 IS is using CipherTool to automatically encrypt passwords in the WebUI. See my comment at the bottom of this post:
Connection issues after turning off embedded LDAP
Has anyone successfully secured a web service using Active Directory credentials instead of an application specific username/password?
I have an application that talks to web services written with Axis2 1.5.1 and deployed on Tomcat 6.0.24, deployed on Linux, FWIW.
I have changed Tomcat from a JDBCRealm, authenticating against a database, to a JAASRealm, configured to access AD with Centrify (the client's preferred solution).
This works with web applications but for web services I get a 403 response.
I have tested using a simple Axis2 service (written with Axis2 1.5.1) and deployed against Tomcat 6.0.24 and 7.0.63. I've also tried with a web service written using Axis2 1.6.2. I get the same result in each case. I'm testing using a browser, BTW. When the service works I get xml; when it doesn't I get the error.
I'm wondering whether I need to change something in axis2.xml since even https://tomcat:8443/HelloWorld (my service is called HelloWorld) generates a 403.
Some configuration details...
I've changed the realm in server.xml to the following
<Realm className="org.apache.catalina.realm.JAASRealm"
appName="CENTRIFYDC"
roleClassName="com.centrify.dc.tomcat.RolesPrincipal"
userClassName="com.centrify.dc.tomcat.LoginPrincipal" />
<Valve className="com.centrify.dc.tomcat.ContextValve" />
In web.xml I have added
<security-constraint>
<display-name>Security Web Service</display-name>
<web-resource-collection>
<web-resource-name>Secured Area</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>USER</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>SPNEGO</auth-method>
<realm-name>CENTRIFYDC</realm-name>
</login-config>
<!-- Security roles referenced by this web application -->
<security-role>
<role-name>USER</role-name>
</security-role>
I've mapped the USER role to one of my AD groups
Any suggestions or guidance or setups that have worked for someone would be very useful, thanks.
The 403 error is indicating the permission problem after authentication. It is because after SSO, the server will check for group membership to see if the user got proper permission. The 403 error is coming from the configuration part of role mapping. SSO to the server is actually working fine.
We would suggest you to try the following(the following example is using 5.5 version tomcat but it will be the same for later version):
Configure tomcat for Centrify
a. Configure tomcat for Centrify by using configure.pl:
cd /usr/share/centrifydc/java
./configure.pl
Enter /opt/apache-tomcat-5.5.25 when prompted for the tomcat directory.
Enter /usr/jdk1.5.0_15 when prompted for the java directory.
Enter y when prompted if you want to configure Tomcat for SSL
Enter n when prompted if you want to configure Tomcat for SSL communication with ADFS server
Take default for everything else.
Configure webdav for Centrify and use kerberos(SPNEGO) for authentication
a. Set the logon realm to CENTRIFYDC:
cd /opt/apache-tomcat-5.5.25/webapps/
mkdir webdav/META-INF
create webdav/META-INF/context.xml as:
<Context path="/webdav">
<Realm className="org.apache.catalina.realm.JAASRealm"
appName="CENTRIFYDC"
roleClassNames="com.centrify.dc.tomcat.RolesPrincipal"
userClassNames="com.centrify.dc.tomcat.LoginPrincipal"/>
<Valve className="com.centrify.dc.tomcat.ContextValve"/> </Context>
b. Configure mapping of AD groups to roles for the jspwiki app.
cp /usr/share/centrifydc/java/templates/centrifydc.xml webdev/WEB-INF/centrifydc.xml
modify RoleMapping section in webdev/WEB-INF/centrifydc.xml as follow:
<RoleMapping separator=";">
<Role name="user" group="*" user="*"/>
<Role name="#ROLE2#" group="#GROUP2#"/>
<Role name="#ROLE3#" user="#USER3#"/>
</RoleMapping>
c. Configure web.xml to use kerberos(SPNEGO) for authentication:
Edit web.xml and add
<login-config>
<auth-method>SPNEGO</auth-method>
<realm-name>Default</realm-name>
</login-config>
<!--
OPTIONAL: Add CentrifyFilter to set the authenticated user's attributes
such as group membership in HTTP headers. You must also configure the
<SetHeaders> element in centrifydc.xml to set user attributes in HTTP
headers.
This filter is not needed if you do not want the authenticated
user's attributes set in HTTP headers.
-->
<filter>
<filter-name>CentrifyFilter</filter-name>
<filter-class>com.centrify.dc.wbase.DCFilter</filter-class>
</filter>
<!--
OPTIONAL: Apply (map) CentrifyFilter to the url patterns in the
<security-constraint> section of this application to set the
authenticated user's attributes in HTTP headers.
This <filter-mapping> is not needed if you do not want the
authenticated user's attributes set in HTTP headers.
-->
<filter-mapping>
<filter-name>CentrifyFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<security-constraint>
<web-resource-collection>
<web-resource-name>ProtectedResource</web-resource-name>
<url-pattern>/index.html</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>user</role-name>
</auth-constraint>
</security-constraint>
<security-role>
<description>
An test role
</description>
<role-name>user</role-name>
</security-role>
You could also refer to the Centrify Java Guide p.135 for the example for role mapping configured as follow:
Extensible Markup Language (XML) files, like the centrifydc.xml file, are structured documents that contain a set of supported elements enclosed in opening and closing angle (< >) brackets. The elements can be required or optional depending on the requirements of the application. The following is an example of how the key elements defined in the centrifydc.xml file:
<Centrifydc>
<enableAuthSchemes>Negotiate,NTLM,Basic</enableAuthSchemes>
<adclientSocket>/var/centrifydc/daemon</adclientSocket>
<RoleMapping>
<Role name=”role1” group=”arcade.com/Users/Sales”/>
</RoleMapping>
</Centrifydc>
Although the template centrifydc.xml file contains some default settings, these default settings should be modified in the copy of the centrifydc.xml file you place in an application’s WEB-INF directory. The following table describes the elements you can set in the centrifydc.xml file.
If you need any further assistance, please feel free to contact Centrify Technical Support directly.
There were a couple of problems. The first was an error was in the server.xml file. JAASRealms can accept several classes for role and user so the properties are roleClassNames and userClassNames as follows
<Realm className="org.apache.catalina.realm.JAASRealm"
appName="CENTRIFYDC"
roleClassNames="com.centrify.dc.tomcat.RolesPrincipal"
userClassNames="com.centrify.dc.tomcat.LoginPrincipal" />
The second issue is around using several applications which use different authorization. The centrifydc.xml file maps roles when the app is first authenticated. However, if org.apache.catalina.authenticator.SingleSignOn is enabled then the roles are set only for the application that performs the authentication. Thereafter, only the roles set in the authenticating application's centrifydc.xml file are set. Other applications will see that the user is already authenticated but does not have the necessary authorization and fail with a 403 error.
In different applications use the roles user, USER and manager then the logging-in application must set up all three roles when it authenticates.
I have a WSDL for a Web Service and a Public Key Certificate in the shape of a .cer file.
I need to get SoapUI to encrypt the service request with the public key of the certificate.
How do I do this?
In SoapUI, go to the Preferences dialog, under the File menu. There's a tab/section for SSL. There you can specify the path to the .cer file. I don't have it here in front of me, and I've only done .pfx, but it should work the same. With .pfx, you need to enter the password - not sure if you do that for .cer or not. You can also convert the .cer to .pfx if that works better. But anyway, with a .pfx specified here, I was able to use https connections to our server (Cisco ACE gateway actually) which required "client certificate authentication". It was easy to do in SoapUI, proving that the infrastructure was set up right. Our app, written in Delphi2005, took another 3 weeks... But at least we knew what we were trying to do, and had a way to verify the result.
In Preferences fill in the path to your certificate in the KeyStore field and the password underneath.
I use a p12 certificate and it seems to be working fine.
If you can use WCF, just add security to the binding, and the following behavior:
<behaviors>
<behavior>
<clientCredentials>
<clientCertificate findValue= "101010101010101010101010101010000000000"
storeLocation="LocalMachine" storeName="The logic storage"
X509FindType="The cert name"/>
</clientCertificate>
</clientCredentials>
</behavior>
</behaviors>
More info about how to enable security in WCF, see: MSDN