I cannot find a way to encrypt the keystore password in the json configuration files that are used in the WSO2 EMM.
There is a notable documentation for encryption of the sensitive information in the xml configuration files for the EMM product, but nothing for the json configuration files.
My question is about encrypting the keystore password in the json configuration files.
Secure vault uses the xpath to specify the location that we want to encrypt. Therefore currently secure vault does not support encrypting .json and properties files.
Related
I have been following this sample from AWS. I have followed the guide, downloaded the certificates, converted them into .pfx and tested them in a local code similar to the sample. The code works fine and the intended connection can be established. However, when I try to upload the certificate to Azure Key Vault, I get this error:
The specified X.509 certificate content is invalid. Error: one or more x.509 properties are invalid.
I have Googled and tested quite a few different openssl commands, and also tried to upload through PowerShell (just incase), but its always the same error. I am a bit clueless as to why this (as far as I know) official AWS example does not just work, and why I can not just export certificates from one big cloud company to another.
Does anyone have any guesses as to what is going wrong and what properties may be invalid, or how I can find out?
PS: My Azure code is getting all configurations from the Key Vault secrets (connection strings, etc). I figured it could similarly be used to store certificates that my code can retrieve and use, instead of storing the certificate file in the project. Do let me know if I have misunderstood what kind of certificates should be saved in the Key Vault.
Please check if following can be worked around:
Please note that Key Vault requires /accepts only a PEM or PFX file
along with a private key.
If you have a private key stored separately in a different format,
you need to combine the key with the certificate and key should not
be encrypted. Some certificate authorities (CAs) provide certificates
in other formats. Therefore, before you import the certificate, make
sure that it's in either PEM or PFX file format and it uses key
either (RSA) or elliptic-curve cryptography (ECC) encryption. see
creating a certificate with a ca not partnered with key-vault
Some factors to check:
Please check if the Pfx was expired or Pfx password is incorrect or
has an invalid format.
Try Re-importing the cert from a pfx file with the --password
parameter if it is password protected.
Also make sure you have access policies created create,get
,set,delete ,list for user that is trying to create and also for the
application.
And the name of the secret or certificate that you are uploading
must be unique and should not match with any other secret that was
created previously. Content-type must be application/x-pkcs12 for
pfx file.
Also check the similar case from SO reference
References:
Understand X.509 public key certificates | Microsoft Docs /About Azure Key Vault Certificates
"The parameter KeyVault Certificate has an invalid value"- Microsoft
Q&A
while using wso2is-5.6.0
"travelocity.com" application is configure with wso2 identity server to authentication from Facebook am getting this error
org.wso2.carbon.identity.sso.agent.exception.SSOAgentException: Signature validation failed for SAML Response
after google search there some mention that upload certificate file but am not getting this point which certificate file and from where i will get certificate file to upload in identity provider in wso2 identity server
This happens because, your travelocity sample doesn't have the certificate which is corresponding to the key used by Identity server to sign the SAML response. One of the easiest options is to replace the key stores of your travelocity sample with the ones inside WSO2 identity server (Assuming you are using out of the box setup). You can find the key stores in your identity server distribution /repository/resources/security directory. Copy two key stores (wso2carbon.jks and client truststore.jks) to your /WEB-INF/classes. (yes you need to replace existing ones).
Or else if you have changed keys in your wso2 IS, the proper way to do fix this is, export the public key from Identity Server (from wso2carbon.jks) and import it to both (wso2carbon.jks and clinttrustore.jks) in travelocity sample. You can use keytool commands to achieve this.
I am attempting to import a service provider into my WSO2 Identity Server by using code. This tutorial seems to be saying that I to add my service provider xml configuration file to the WSO2_HOME/repository/identity/service-providers folder. However, it's a bit difficult to understand so I'm afraid I'm doing something wrong.
My requirements are:
Set up OAuth service provider through code
Include clientID, clientSecret, grant types, etc. in the .xml config files
My observations are as follows:
If I put my service provider .xml file into the WSO2_HOME/repository/identity/service-providers folder before I have ever started my WSO2 server, the XML file is read and I can authenticate against it.
If I put my service provider .xml file into the WSO2_HOME/repository/identity/service-providers folder on a subsequent WSO2 server startup the file is not read from the service-providers folder.
I see the tutorial mention the file sso-idp-config.xml but I'm not sure where that comes into play. Do I need to utilize that file somehow?
I am confirming that service providers in observation 2 aren't being loaded into the server by both looking at the data in the H2 database (a row isn't written for the service provider in the SP_APP table) and attempting to authenticate against the service provider using a REST call
The tutorial I linked seems pretty comprehensive but it give directions for SAML authentication. Is there a resource/instructions I can use to do a code-first OAuth approach?
From IS 5.7.0 supports import and export complete service provider configuration as the xml file. Here is the corresponding documentation. So I think you can use the respective admin service(ApplicationManagementService) to import the OAuth application from your code.
You can refer this doc to get the call the admin service.
I'm trying to do something that seemed simple but ends up being difficult because I lack the expertise.
I have an APIM deployed with no customisation security-wise (don't worry, it's not production!). So it's only got carbon.jks.
I authenticate users in an application with SAML2 against an IDS, then use the APIM with an app secret for a user token generated from the SAML2 token. I get from the APIM an OAuth token which I use to call APIs in the APIM. (note that I managed to resolve this thanks to another post here some time ago :-) )
The backend that implements the APIs receives a JWT as a result, with header, user information and app information, and a signature.
For my first tests I write my own "hello world" backend, that logs the JWT.
I use http://jwt.io which manages to read my JWT without any problem. But it tells me the signature is invalid.
To make the signature valid I would need a valid public key.
I don't know where to find that key.
I have run the command line described in RSA Public Key of WSO2carbon and generated a .cert file. I have examined the .cert file in portecle (http://portecle.sourceforge.net/) but found nothing of interest, however opening it in Windows gave me a field "public key", which looks like "30 81 89 02 81 81 00 94 a[...]", quite long and obviously hex.
I tried this, and also its base64-encoded representation, in http://jwt.io but no success.
Because I was wondering where my public key is, I have also read:
How to validate a JWT from WSO2 API Manager
(and the referenced link https://asankad.org/2013/12/05/obtaining-certificate-used-to-sign-a-jwt/ )
However the code provided is a bit on its own, with not even a mention of language. I assume it's node.js, but no info about libs or anything.
Here are some more precise questions:
WSO2 APIM offers only SHA256withRSA (which is a flavor of SHA2 IIUC). wso2carbon.jks cert that I found were sha1. So I'm supposing that could not have worked anyway. How can APIM generate SHA256 with SHA1 certificates?
WSO2 APIM offers only SHA256withRSA. http://jwt.io gives the choice between RS256 and HS256, one uses a key, the other a secret (public/private). I'm guessing I need to use RS256? (but again the only keys I have seem to come from SHA1 certs)
has anyone succeeded in what I'm doing? Install WSO2 APIM, generate a JWT and validate the JWT against http://jwt.io, including signature?
If I use a lib such as https://github.com/tymondesigns/jwt-auth to validate the JWT, will it work? I was told that this lib doesn't support SHA256.
in the APIM I'm in a tenancy, called sandbox. If I go to the super-tenancy carbon I see wso2carbon.jks. If I go to my own tenancy's carbon I see sandbox.jks, but it's empty, and on the deployment machine there's no corresponding file. How does that work out, does the tenancy JKS exist only when used, or is it stored in the DB and not filesystem?
how much can I show of my tokens, JWT etc on a public forum? :-) (if it helps to help me, I'm willing to share!)
Thanks for any tips!
(maybe all I need is the default public key, seeing as I'm using the default keystore!)
Answering myself in case anyone has the same issue.
Two things helped me out:
first, to validate in jwt.io, I needed to change the cert encoding by running the following command: openssl x509 -inform der -in somekey.cer -out somekey.pem
then I was using the super-tenant keystore instead of the tenancy keystore. I had looked into this but not found any tenancy keystore on the APIM VM. I had to:
log in as tenant admin in APIM carbon portal
navigate to configure / keystores
there was a keystore for the tenancy (called sandbox1.jks), click on public key
save the downloaded sandbox1.cert and convert it to pem using the above command
The resulting pem worked fine with jwt.io using RS256
Hope this helps others!
I am attempting to configure our WSO2 Identity Server (5.1.0) to talk to our Shibboleth Identity Provider v3 (3.2.1) server.
When I attempt to authenticate, I get an error in my Shibboleth IdP logs which suggests to me that my metadata for the WSO2 server is wrong:
2016-06-30 15:24:48,564 - DEBUG [org.opensaml.saml.metadata.resolver.impl.AbstractMetadataResolver:334] - Metadata backing store does not contain any EntityDescriptors with the ID: MYENTITYID
2016-06-30 15:24:48,564 - DEBUG [org.opensaml.saml.metadata.resolver.impl.BasicRoleDescriptorResolver:198] - Metadata document did not contain a descriptor for entity MYENTITYID
2016-06-30 15:24:48,564 - DEBUG [org.opensaml.saml.metadata.resolver.impl.BasicRoleDescriptorResolver:281] - Metadata document did not contain any role descriptors of type {urn:oasis:names:tc:SAML:2.0:metadata}SPSSODescriptor for entity MYENTITYID
2016-06-30 15:24:48,564 - DEBUG [org.opensaml.saml.metadata.resolver.impl.BasicRoleDescriptorResolver:252] - Metadata document does not contain a role of type {urn:oasis:names:tc:SAML:2.0:metadata}SPSSODescriptor supporting protocol urn:oasis:names:tc:SAML:2.0:protocol for entity MYENTITYID
I'm following documentation from the WSO2 site here:
https://docs.wso2.com/display/IS510/How+To%3A+Configure+Shibboleth+IdP+as+a+Trusted+Identity+Provider
I have the Shib IdP v3 working with other services, but a very new to that version and don't generally dig deep into Shibboleth anyway beyond setting up attribute resolution and release for relying parties.
Could someone with more experience in either the Shibboleth IdP arena or the WSO2 Identity Server arena point me in the direction of resolving this or at least narrowing down whether it's a general IdP configuration issue or a WSO2 metadata issue ?
The documentation from WSO2 site is based on Shib IdP v2.
You can still use it on v3, but you would need to enable v2 compatibility
https://wiki.shibboleth.net/confluence/display/IDP30/NameIDGenerationConfiguration
There is no need though, the steps for v3 are quite similar.
AFAI can tell, Shibboleth does not support the unspecified name id format. It could be possible to tweak it to support it, but I have not found issues letting Shibboleth use the transient format. Likewise, I see reason to not use a persistent name id either. Thus, there is no need to modify the name id configuration.
The AttributeFilterPolicy is now defined on file /conf/attribute-filter.xml (or the attribute filter file loaded by /conf/services.xml). This policy specifies which attributes can be disclosed to each SP, so you need one entry for each of your SPs.
Since IS does not support metadata files yet, you need to tailor one and save it at /metadata/wso2is.xml The one in the WSO2 Site is a good start. Just keep in mind that the NameID Format does nothing if it requires the unspecified format, and that you might want to pass additional attributes in the SPSSODescriptor, in my case I had to add the following: AuthnRequestsSigned="true" WantAssertionsSigned="true". I also added the signing and encrypting x509 certificates that WSO2IS will use when sending requests to Shibboleth.
Next, you need to tell Shibboleth that you want to use that metadata file by adding something like the following to file /conf/metadata-providers.xml
<MetadataProvider id="wso2is"
xsi:type="FilesystemMetadataProvider"
metadataFile="%{idp.home}/metadata/wso2is.xml">
</MetadataProvider>
Now, when you configure the IdP on WSO2IS, you need to map the claims/attributes that Shibboleth shares with WSO2IS (as defined in Shibboleth by /conf/attribute-filter.xml) to the WSO2 IS dialect. To do that, you go to your IdP configuration, expand Claim Configuration, then expand Basic Claim Configuration, there you can add as many claim mappings as you need.This is an example of the Claims Mappings
I hope this helps.