I'm using Firebird 3 with encryption via the AES128 plugin found here. https://www.ibphoenix.com/products/software/encryptionplugin
I have successfully encrypted the database, and I am able to connect and query it using isql however I am not able to connect from within my ColdFusion CFIDE - Data Sources area. I previously used the dbcrypt plugin and it worked fine, it was just tremendously slow compared to the un-encrypted database. With the AES128 plugin though, I get the error
Connection verification failed for data source: devBBL
java.sql.SQLException: Unsupported operation code: 97 The root cause
was that: java.sql.SQLException: Unsupported operation code: 97
My connection information in the CFIDE Data Sources window is the same as it's always been.
JDBC URL: jdbc:firebirdsql:localhost/3050:C:\fbdb\MASTER25.FDB
Driver Class: org.firebirdsql.jdbc.FBDriver
Driver Name: JayBird
Username: SYSDBA
Password: PASSWORD
Does anyone have any idea what is causing me to receive this error when trying to connect? Do I need to include some additional argument?
This happens if the database is encrypted and the plugin requires a callback to get the key (instead of using a server-local encryption key).
If configured to use a callback to obtain the encryption key, during the attach phase, Firebird will send a packet with operation code op_crypt_key_callback (= 97) (and plugin specific data) to the client, and the client in turn should respond to that with the encryption key (or at least, with plugin specific data that the plugin can use to derive the encryption key).
Jaybird versions before 3.0.4 do not support handling of encryption key callbacks (operation code 97), so this error occurs.
Basic support to pass a fixed response to an encryption key callback has been introduced in Jaybird 3.0.4. For earlier versions, if you can't upgrade, the workaround would be to use a server-local encryption key.
Solution
The solution is to upgrade Jaybird to Jaybird 3.0.4, which introduced support for database encryption callbacks. If the encryption plugin performs a callback, but doesn't actually need to use the content of the response, then it will work out of the box.
It the encryption plugin needs a reply with the key, you can set the key in the dbCryptConfig connection property. You can either use a base64 encoded value by prefixing it with base64: or a string key, which will be converted to bytes using UTF-8 encoding.
For example in a connection string:
jdbc:firebirdsql://localhost/appdbalias?dbCryptConfig=base64:dmVyeXNlY3JldGtleQ==
or
jdbc:firebirdsql://localhost/appdbalias?dbCryptConfig=verysecretkey
The implementation currently does not support more advanced callbacks.
Jaybird 3.0.4 (or higher) can be downloaded from https://www.firebirdsql.org/en/jdbc-driver/
See Jaybird 3.0.x release notes, section Database encryption support for more information.
Workaround
NOTE Only use this workaround if you can't yet upgrade to Jaybird 3.0.4 or higher.
According to the instructions on https://www.ibphoenix.com/products/software/encryptionplugin you can configure a server-local key by using KeyHolderPlugin = KeyFile instead of KeyHolderPlugin = Callback.
Unfortunately, this doesn't work. It looks like the plugin in question is unconditionally performing a callback to the client, even if it has the necessary data available locally. This is possibly a bug in this encryption plugin, or maybe a deliberate design decision.
IBPhoenix has released a new version of this plugin, version 1.2.1, which allows you to disable this callback with an explicit setting in plugins/KeyFile.conf with setting DisableCallback = true.
Related
I am able to connect to Db2 on z/OS with the IBM universal JDBC driver file db2jcc4.jar using IBM JDK 1.8 that is bundled with WebSphere 9. Every thing works fine and I can browse the catalog and execute queries. I used Squirrel SQL version 4.0.0.
But when I switch my JDK to the Open JDK 8 or 12 while keeping everything else the same, I get the following error. What should be done to fix this error? What is the difference between IBM JDK and Open JDK, which causes the DB2 connection to work with one JDK and fail with the other?
Here is one of matching articles of your case:
JDBC application may receive error "Security mechanism not supported"
https://www.ibm.com/support/pages/jdbc-application-may-receive-error-security-mechanism-not-supported
Resolving The Problem
Set the following property :
securityMechanism = ENCRYPTED_USER_PASSWORD_AND_DATA_SECURITY (13)
Alternatively you can set property retryWithAlternativeSecurityMechanism to YES(1).
Hope this helps.
According to IBM's documentation for their IBM Data Server Driver for JDBC and SQLJ, error code -4214 is an "Authorization failed" error -- and you know that much. But you can get more specific information about the problem if you call SQLException.getMessage. I think you may have done that already, but it's not entirely clear.
My semi-educated guess is that you haven't yet followed the configuration steps in IBM's driver documentation in the section "Configuring the Java Runtime Environment to Use SSL":
https://www.ibm.com/support/knowledgecenter/SSEPGG_11.5.0/com.ibm.db2.luw.apdv.java.doc/src/tpc/imjcc_t0054066.html
You'll have to apply some common sense knowledge to those instructions to adapt them for the OpenJDK, and this might not be an IBM supported combination depending on what/how you do it. If you can somehow use the IBMJSSE2 Provider, that'd be nice.
I think Mao and Mustaccio probably have the right ideas, and probably you're just missing the server certificate in your truststore. The instructions linked above walk you through how to configure that.
I am inserting a record in aerospike. Everything is working fine on my local environment. However, on the staging environment, UTF-8 characters are not being stored correctly.
aql> select msg from test.msges
LIST('["{"message_id":"kxwFZHVBKj","title":"คำถามได้รับà¸à¸²à¸£à¸•à¸à¸šà¸à¸¥à¸±à¸šà¹à¸¥à¹‰à¸§!","actions":
|
+----------------------------------------------------------------------------------------------------------+ 1 row in set (0.038 secs)
Also, this is being done using a golang clinet which is pretty UTF-8 safe i.e. no problems of byte-to-string or string-to-byte conversions and this works fine on local, hence
I am assuming this has something to do with aerospike configuration or version. The aerospike version on my local is 3.14.1.1 and on staging is 3.9.1.1.
One more thing I noticed based on the c-client comments coming on this post is that on my local machine I get the following aql version:
Aerospike Query Client Version 3.13.0.1 C Client Version 4.1.6
But on the remote I have the following:
Aerospike Query Client Version 3.9.1.2
The C-client version is missing !
Anyone can help what configuration (or whatever) am I missing here ?
aql is a tool written in c-client. In c-client, the application is expected to handle utf-8 encoding as there is no "string" datatype similar to newer generation languages that support multibyte utf-8 characters. The application reading data should have prior knowledge that the data is indeed written with utf-8 encoding to handle that. aql cannot determine that as it is a generic tool. So, it ends up printing each byte as a character.
Hy Guys,
I have been trying to integrate spring sample app, downloaded from https://github.com/spring-projects/spring-security-saml, with Ping Federate. I have used this sample app to integrate with so many other IDPs and it worked fine without any hassles. But Ping Federate seems to be bit complicated. This is what I did so far.
Create connection in Ping using my SP meta data.
Export Ping meta data
Configure it in my SP (securityContext.xml)
Start the server
I get various errors at various scenarios. The one which I am currently testing,
has following error on server restart,
org.opensaml.saml2.metadata.provider.MetadataProviderException: No IDP was configured, please update included metadata with at least one IDP
On investigating the logs, I see the root cause to be
Caused by: java.lang.NullPointerException
at org.opensaml.saml2.common.SAML2Helper.getEarliestExpiration(SAML2Helper.java:112)
at org.opensaml.saml2.metadata.provider.AbstractReloadingMetadataProvider.processCachedMetadata(AbstractReloadingMetadataProvider.java:328)
at org.opensaml.saml2.metadata.provider.AbstractReloadingMetadataProvider.refresh(AbstractReloadingMetadataProvider.java:258)
However, everything works fine if I disable metadataTrustCheck in securityContext.xml using property
< property name="metadataTrustCheck" value="false"/>
Can some one please help? I have been trying to solve this past one week. Unfortunately there is no good enough documentation from Ping for the version (latest) I am using.
Update:
Application works fine if,
Metadata trust check is disabled at SP and PF metadata is signed
Metadata trust check is enabled at SP and PF metadata is unsigned
However, I am getting above NullPointerException if
Metadata trust check is enabled at SP and PF metadata is signed
A while ago, we had exactly the same NullPointerException with IDP metadata (using opensaml 2.6.4). As written above, setting metadataTrustCheck="false" on the ExtendedMetadataDelegate did solve the problem, but was not the desired solution.
Alternatively, one could have removed the <Signature> block from the metadata, which is equally as bad.
Solution:
Besides adding the (self-signed) certificate, it was necessary to add the next certificate in the chain to the keystore as well.
For the interested reader:
Despite this error, the application continued to start and claimed "Reloading metadata was finished".
However, there's a TimerTask, which regularly checks whether metadata providers where changed i.e., if a new one was registered. Supposedly, this happens only at startup time.
Regardless, every 10 seconds (by default), a refresh is triggered internally, which leads to calculation of the expiration time. If the metadata is not loaded for any reason e.g., because of a validation error, then this leads to the mentioned NullPointerException in getEarliestExpiration().
If you're using a file-based MetadataProvider you might want customize the CachingMetadataManager and set refreshCheckInterval="-1" to disable this TimerTask.
PS: Maybe there are other reasons like a typo in the entityID, an overdue validUntil, expired certificates,... you name it. Anything, which causes the metadata not to be loaded will likely result in this issue. Another indicator is the following exception:
Caused by: org.opensaml.saml2.metadata.provider.MetadataProviderException: Metadata for issuer <ENTITY_ID> wasn't found
I'm trying to do this:
import groovy.sql.Sql
def sql = Sql.newInstance(
url:'jdbc:sqlserver://localhost\\myDB',
user:'server\user', //this I don't think I need because of SSPI
password:'password',
driver:'com.microsoft.sqlserver.jdbc.SQLServerDriver',
SSPI: 'true'
)
The problem I'm having is that this connection is just timing out. I can ping the machine. I can also connect to the database with Managment Studio logged into my SSPI user (or whatever you call it, I start the Management Studio with a different user)
So I've tried that with my SoapUI as well, started the program as a different user, but I still time out when I initiate the connection. So something is very wrong with my connection string and any help would be appreciated.
P.S. Yes, I don't know what's up with the \ backslashes after the URL to the server, I guess it indicates that it's at the root. If I don't use them I get a message that I'm on the incorrect version.
And then we found the answer..... First of all I had the wrong JDBC driver installed. You need to head over to microsoft to get the real deal:
https://www.microsoft.com/en-us/download/details.aspx?id=11774
Then you need to unpack this one, place the 4 or 4.1 version in your bin directory of SoapUI. (You are apparently supposed to use Lib/Ext, but that doesn't work for me)
Then, since we are trying to use SSPI or Windows Authentication, to connect to the SQL server, you need to place the sqljdbc_auth.dll from the driver/enu/auth folder. This is used in one of your path's or in SoapUI Lib folder. Remember to use the 32 bit dll for 32 bit SoapUI!!! I did not since my system is 64.....
After this, I used this string, but now you have the setup correct, so it should work fine as long as you remember to start SoapUI up using the correct windows user. (Shif-right click - start as different user - use the same user you have started the SQL server with)
Again, I wasn't completely aware of this from the start (yes, total newbie here) and it failed.
Finally, when you have done all this, this is the string that works - and probably a lot of derivatives since the failing part here were the driver and dll.
def sql =Sql.newInstance("jdbc:sqlserver://localhost;Database=myDB;integratedSecurity=true","com.microsoft.sqlserver.jdbc.SQLServerDriver")
I have a little java program that reads a db2 table via jdbc. This program is invoked via "tso bpxbatch myjavatool".
I wonder if there is the possibility to "pass" the username/password of my TSO user to the JDBC driver?
For example, if I connect to DB2 with a simple REXX script I don't have to specify my username/password again and DB2/RACF checks if my user is allowed to execute the SQLs.
Now my java tool is not running in my TSO address space but under the control of the J9 in the USS address space...
Is there also a way to automatically log in to DB2 with the current TSO user?
I don't know too much about BPXBATCH, but I assume you are still running under your own userid in the USS-address-space.
In your java-code you should be able to get your userid via
String user = System.getProperty("user.name");
As for the password you could try using RACF-Passtickets instead. There is a library IRRRacf.jar in /user/include/java_classes and the corresponding javadoc in IRRRacfDoc.jar in the same directory. the code for generating the Passticket is rather simple:
IRRPassTicket generator = new IRRPassTicket();
String ptkt = generator.generate(user,applid);
then just pass the passticket instead of the password and you should be fine.
Alas, there's several aspects you have to make sure of before using this approach:
Set up RACF to use Passtickets for DB2 - it might already be configured, else you'll have to set up proper profiles in the PTKTDATA-class (See RACF-documentation for more details)
Make sure each user running the code has the proper RACF authorization to use the r_ticketserv callable service (again, see RACF documentation)
Find the correct application-name (applid) for your DB2-system. See the DB2-documentation about using passtickets.