You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by Zachary Bedell <zb...@nycourts.gov> on 2016/08/11 20:15:57 UTC
Oracle XA Datasource password encryption (doc bug?)
Not sure whether this falls under wrong documentation or incorrect behavior, but I found the existing docs for setting up encrypted database passwords for Oracle XA datasources don't work in TomEE 7.0.1.
My goal is to use a custom PasswordCipher since we have apps with encrypted passwords for a legacy application server. It would be convenient to enable using the existing encrypted password strings without having to decrypt / re-encrypt them. I wrote a custom PasswordCipher, created META-INF entries, and setup the resources.xml entries as described in http://tomee.apache.org/examples-trunk/datasource-ciphered-password/README.html.
1) Created my.package.PasswordCipher, implements org.apache.openejb.cipher.PasswordCipher.
2) Added META-INF/org.apache.openejb.cipher.PasswordCipher/mycipher which contains my.package.PasswordCipher, ensured that and the class are in a JAR in lib.
3) resource.xml contains:
<Resource id="myPool" type="DataSource">
JdbcDriver oracle.jdbc.xa.client.OracleXADataSource
JdbcUrl jdbc:...
User mewho
Password Y2hhbmdlbWU=
PasswordCipher mycipher
InitialSize 10
MaxActive 50
MaxIdle 10
MaxWait 15000
ValidationQuery "SELECT sysdate FROM DUAL"
TestOnBorrow true
TestOnReturn true
TestWhileIdle true
TimeBetweenEvictionRunsMillis 60000
AccessToUnderlyingConnectionAllowed true
JtaManaged true
</Resource>
The password was never decrypted in this case. I verified with both debugger breakpoints & System.out's that my PasswordCipher's decrypt method was never called.
I had to remove Password & PasswordCipher from the Resource and use "VaultPassword cipher:mycipher:Y2hhbmdlbWU=" instead. That works.
I've run into other situations where Oracle XA seems to behave a little differently than other datasource types in TomEE (including requiring "User" instead of "UserName" as the property key), though I'm not clear on why that is.
Is this something where the documentation needs an "except OracleXA" addition, a change in behavior in TomEE 7.0.1 (which I'm using) that the docs haven't caught up with, or a bug?
What I've got now looks like it works, but if it's not the "right" way, I'd prefer to change it and hopefully not end up broken at some point in the future.
Best regards,
Zac Bedell
Re: Oracle XA Datasource password encryption (doc bug?)
Posted by Romain Manni-Bucau <rm...@gmail.com>.
2016-08-12 15:35 GMT+02:00 Zachary Bedell <zb...@nycourts.gov>:
> Is there anything that explains the effective differences between the
> single resource versus dual resource approach? I'm coming from a mostly
> JBoss background, and I don't have anything to relate to the idea of the
> two things being separated.
>
>
Yep,
basically default pools we provide - tomee supports any pool but we only
deliver DBCP and tomcat-jdbc integration in default binaries - the
XADataSource is used as a Connection factory. It means the XA just gives
connection (+ XAResource) to the pool and the pool can handle the user/pwd
or not depending the impl and the way it works.
> With a single resource, are both connection pooling & XA still
> functional? I haven't had to pass both User and UserName to the single
> resource. Passing only User worked with plain-text passwords and also
> works with the "PasswordVault cipher:X:asdf" approach.
>
>
Depends the pool and impl but generally the pool passes the username
configured. If you don't see it and dont ask tomee to skip its defaults
values, default Username is "sa" and can mess up a datasource impl
configuration (and require a forced user depending how you configure it).
> I kind of like having a single resource from a simplicity standpoint.
> Also, selfishly, I have to roll out a migration manual for 100 or so people
> in our org to move 50-ish applications over the next year. The single
> resource approach will make more sense based on their background and save
> me headaches, assuming there aren't drawbacks to using it.
>
>
Yes and not. I fully get your point of view but let's me try to explain
mine:
- with the single resource solution (same as @DataSourceDefinition
properties which are undefinely related to the pool or datasource itself)
you can't handle conflicts between the pool and datasource impl and you can
misunderstand a parameter set on the wrong instance. Also you can have
parameters wired to the wrong setter (ConnectionProperties) and can't keep
using defaults and fix this issue without splitting in 2 resources the
resources. So yes single resource definition works most of the time but
also requires more validations to ensure you did what you think.
- the migration can be made very easy using tomee Template or
ResourceProvider API potentially linked to tomee server events. In this
solution you would create the resource(s) in a shared jar (you add it in
common.loader) and you can just wire the old config to tomee one. In clear:
your users would get this jar (either automatically through a custom tomee
packaging through tomee-maven-plugin or manually with a shared folder for
instance) and just define: <Resource id="jdbc/myDs" type="DataSource" />
-no properties- and all the config would be handled by your converter. This
would make the migration hurtless for all but 1 guy (the one writing the
covnerter).
> Thanks for the clarification,
> Zac Bedell
>
> > On Aug 11, 2016, at 17:12, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
> >
> > Hi
> >
> > This is expected using a single resource for pool AND XADataSource, try
> > splitting it in 2 resources: http://tomee.apache.org/
> datasource-config.html
> >
> > Short summary is you define twice the password on 2 different instances
> and
> > oracle xadatasource doesnt know it at all. Using cipher: notation tomee
> > handles it before injecting the value for the xadatasource and the pool
> > transparently.
> >
> > Le 11 août 2016 22:16, "Zachary Bedell" <zb...@nycourts.gov> a écrit :
> >
> >> Not sure whether this falls under wrong documentation or incorrect
> >> behavior, but I found the existing docs for setting up encrypted
> database
> >> passwords for Oracle XA datasources don't work in TomEE 7.0.1.
> >>
> >> My goal is to use a custom PasswordCipher since we have apps with
> >> encrypted passwords for a legacy application server. It would be
> >> convenient to enable using the existing encrypted password strings
> without
> >> having to decrypt / re-encrypt them. I wrote a custom PasswordCipher,
> >> created META-INF entries, and setup the resources.xml entries as
> described
> >> in http://tomee.apache.org/examples-trunk/datasource-
> >> ciphered-password/README.html.
> >>
> >> 1) Created my.package.PasswordCipher, implements
> org.apache.openejb.cipher.
> >> PasswordCipher.
> >>
> >> 2) Added META-INF/org.apache.openejb.cipher.PasswordCipher/mycipher
> which
> >> contains my.package.PasswordCipher, ensured that and the class are in a
> JAR
> >> in lib.
> >>
> >> 3) resource.xml contains:
> >> <Resource id="myPool" type="DataSource">
> >> JdbcDriver oracle.jdbc.xa.client.OracleXADataSource
> >> JdbcUrl jdbc:...
> >> User mewho
> >> Password Y2hhbmdlbWU=
> >> PasswordCipher mycipher
> >> InitialSize 10
> >> MaxActive 50
> >> MaxIdle 10
> >> MaxWait 15000
> >> ValidationQuery "SELECT sysdate FROM DUAL"
> >> TestOnBorrow true
> >> TestOnReturn true
> >> TestWhileIdle true
> >> TimeBetweenEvictionRunsMillis 60000
> >> AccessToUnderlyingConnectionAllowed true
> >> JtaManaged true
> >> </Resource>
> >>
> >> The password was never decrypted in this case. I verified with both
> >> debugger breakpoints & System.out's that my PasswordCipher's decrypt
> method
> >> was never called.
> >>
> >> I had to remove Password & PasswordCipher from the Resource and use
> >> "VaultPassword cipher:mycipher:Y2hhbmdlbWU=" instead. That works.
> >>
> >> I've run into other situations where Oracle XA seems to behave a little
> >> differently than other datasource types in TomEE (including requiring
> >> "User" instead of "UserName" as the property key), though I'm not clear
> on
> >> why that is.
> >>
> >> Is this something where the documentation needs an "except OracleXA"
> >> addition, a change in behavior in TomEE 7.0.1 (which I'm using) that the
> >> docs haven't caught up with, or a bug?
> >>
> >> What I've got now looks like it works, but if it's not the "right" way,
> >> I'd prefer to change it and hopefully not end up broken at some point in
> >> the future.
> >>
> >> Best regards,
> >> Zac Bedell
> >>
> >>
> >>
>
>
Re: Oracle XA Datasource password encryption (doc bug?)
Posted by Zachary Bedell <zb...@nycourts.gov>.
Is there anything that explains the effective differences between the single resource versus dual resource approach? I'm coming from a mostly JBoss background, and I don't have anything to relate to the idea of the two things being separated.
With a single resource, are both connection pooling & XA still functional? I haven't had to pass both User and UserName to the single resource. Passing only User worked with plain-text passwords and also works with the "PasswordVault cipher:X:asdf" approach.
I kind of like having a single resource from a simplicity standpoint. Also, selfishly, I have to roll out a migration manual for 100 or so people in our org to move 50-ish applications over the next year. The single resource approach will make more sense based on their background and save me headaches, assuming there aren't drawbacks to using it.
Thanks for the clarification,
Zac Bedell
> On Aug 11, 2016, at 17:12, Romain Manni-Bucau <rm...@gmail.com> wrote:
>
> Hi
>
> This is expected using a single resource for pool AND XADataSource, try
> splitting it in 2 resources: http://tomee.apache.org/datasource-config.html
>
> Short summary is you define twice the password on 2 different instances and
> oracle xadatasource doesnt know it at all. Using cipher: notation tomee
> handles it before injecting the value for the xadatasource and the pool
> transparently.
>
> Le 11 août 2016 22:16, "Zachary Bedell" <zb...@nycourts.gov> a écrit :
>
>> Not sure whether this falls under wrong documentation or incorrect
>> behavior, but I found the existing docs for setting up encrypted database
>> passwords for Oracle XA datasources don't work in TomEE 7.0.1.
>>
>> My goal is to use a custom PasswordCipher since we have apps with
>> encrypted passwords for a legacy application server. It would be
>> convenient to enable using the existing encrypted password strings without
>> having to decrypt / re-encrypt them. I wrote a custom PasswordCipher,
>> created META-INF entries, and setup the resources.xml entries as described
>> in http://tomee.apache.org/examples-trunk/datasource-
>> ciphered-password/README.html.
>>
>> 1) Created my.package.PasswordCipher, implements org.apache.openejb.cipher.
>> PasswordCipher.
>>
>> 2) Added META-INF/org.apache.openejb.cipher.PasswordCipher/mycipher which
>> contains my.package.PasswordCipher, ensured that and the class are in a JAR
>> in lib.
>>
>> 3) resource.xml contains:
>> <Resource id="myPool" type="DataSource">
>> JdbcDriver oracle.jdbc.xa.client.OracleXADataSource
>> JdbcUrl jdbc:...
>> User mewho
>> Password Y2hhbmdlbWU=
>> PasswordCipher mycipher
>> InitialSize 10
>> MaxActive 50
>> MaxIdle 10
>> MaxWait 15000
>> ValidationQuery "SELECT sysdate FROM DUAL"
>> TestOnBorrow true
>> TestOnReturn true
>> TestWhileIdle true
>> TimeBetweenEvictionRunsMillis 60000
>> AccessToUnderlyingConnectionAllowed true
>> JtaManaged true
>> </Resource>
>>
>> The password was never decrypted in this case. I verified with both
>> debugger breakpoints & System.out's that my PasswordCipher's decrypt method
>> was never called.
>>
>> I had to remove Password & PasswordCipher from the Resource and use
>> "VaultPassword cipher:mycipher:Y2hhbmdlbWU=" instead. That works.
>>
>> I've run into other situations where Oracle XA seems to behave a little
>> differently than other datasource types in TomEE (including requiring
>> "User" instead of "UserName" as the property key), though I'm not clear on
>> why that is.
>>
>> Is this something where the documentation needs an "except OracleXA"
>> addition, a change in behavior in TomEE 7.0.1 (which I'm using) that the
>> docs haven't caught up with, or a bug?
>>
>> What I've got now looks like it works, but if it's not the "right" way,
>> I'd prefer to change it and hopefully not end up broken at some point in
>> the future.
>>
>> Best regards,
>> Zac Bedell
>>
>>
>>
Re: Oracle XA Datasource password encryption (doc bug?)
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi
This is expected using a single resource for pool AND XADataSource, try
splitting it in 2 resources: http://tomee.apache.org/datasource-config.html
Short summary is you define twice the password on 2 different instances and
oracle xadatasource doesnt know it at all. Using cipher: notation tomee
handles it before injecting the value for the xadatasource and the pool
transparently.
Le 11 août 2016 22:16, "Zachary Bedell" <zb...@nycourts.gov> a écrit :
> Not sure whether this falls under wrong documentation or incorrect
> behavior, but I found the existing docs for setting up encrypted database
> passwords for Oracle XA datasources don't work in TomEE 7.0.1.
>
> My goal is to use a custom PasswordCipher since we have apps with
> encrypted passwords for a legacy application server. It would be
> convenient to enable using the existing encrypted password strings without
> having to decrypt / re-encrypt them. I wrote a custom PasswordCipher,
> created META-INF entries, and setup the resources.xml entries as described
> in http://tomee.apache.org/examples-trunk/datasource-
> ciphered-password/README.html.
>
> 1) Created my.package.PasswordCipher, implements org.apache.openejb.cipher.
> PasswordCipher.
>
> 2) Added META-INF/org.apache.openejb.cipher.PasswordCipher/mycipher which
> contains my.package.PasswordCipher, ensured that and the class are in a JAR
> in lib.
>
> 3) resource.xml contains:
> <Resource id="myPool" type="DataSource">
> JdbcDriver oracle.jdbc.xa.client.OracleXADataSource
> JdbcUrl jdbc:...
> User mewho
> Password Y2hhbmdlbWU=
> PasswordCipher mycipher
> InitialSize 10
> MaxActive 50
> MaxIdle 10
> MaxWait 15000
> ValidationQuery "SELECT sysdate FROM DUAL"
> TestOnBorrow true
> TestOnReturn true
> TestWhileIdle true
> TimeBetweenEvictionRunsMillis 60000
> AccessToUnderlyingConnectionAllowed true
> JtaManaged true
> </Resource>
>
> The password was never decrypted in this case. I verified with both
> debugger breakpoints & System.out's that my PasswordCipher's decrypt method
> was never called.
>
> I had to remove Password & PasswordCipher from the Resource and use
> "VaultPassword cipher:mycipher:Y2hhbmdlbWU=" instead. That works.
>
> I've run into other situations where Oracle XA seems to behave a little
> differently than other datasource types in TomEE (including requiring
> "User" instead of "UserName" as the property key), though I'm not clear on
> why that is.
>
> Is this something where the documentation needs an "except OracleXA"
> addition, a change in behavior in TomEE 7.0.1 (which I'm using) that the
> docs haven't caught up with, or a bug?
>
> What I've got now looks like it works, but if it's not the "right" way,
> I'd prefer to change it and hopefully not end up broken at some point in
> the future.
>
> Best regards,
> Zac Bedell
>
>
>