Using connection properties

[chazware]

On Thu, 2010-07-15 at 16:32 -0400, Charles Simon wrote:

> I am trying to use the additional properties.  The "key=value" pairs 
> after the semi-colon in the URL or set as 
> TeiidDataSource.setAdditionalProperties(...).
> 
> I cannot figure out where/how these additional properties get passed to 
> my translator.  When are they available so I can capture them for use in 
> my ResultSetExecution object?  I thought they would get passed into my 
> subclasses for ExecutionFactory or BasicConnetionFactory.  Or possibly 
> they need to parameters of my BasicConnction subclass?
> 
> What am I missing?
> 

Reply from: [e-mail]

No, they never get passed to your Translator. These are connection
properties that may be dynamic in nature, that *may* influence the how
query results are generated based if passed to translator. Once the VDB
is built, the generation of the results is defined, and should be same
for all users. So, no per user properties.

[chazware]

The follow up to this is that I do wish to use connection properties to effect how a query is run.  How to I access these properties during my execution of the quesry in my ResultsetExecution subclass.

[chazware]

Let me be a little more explict.

I can use the VDB properties in the <model> or <translator> tag to access the meta data but I need to control execution by specifying a back end server userid and password when a connection is made by a client.

This userid and password are NOT known to JBoss.  They are only known to the back end server that my translator is talking to.  How do I do this?  Do I need to build and configure a login module in JBoss that asks my back end server to verify the userid?  If so this sounds like it would be more work than I would want to do.

[rareddy]

Thanks for using the forums. This is much better.

What I gather from your comment is that,  you developed the "Translator" that has knowledge of your backend  server, so it needs the user credentials for connecting to it. Before 7.0, Teiid used the same paradigm and it is riddled with issues.  So, in 7.0 we split the old Connector into Translator + Resource Adapter and gave explicit roles to each.

Translator is a static component that understands the connection object from resource adaptor and also knows how to interpret Teiid queries coming in into commands that Resource Adapter's connection can understand. Where as Resource Adapter is generic JEE Connector (some times these can be off the shelf products), that only knows how to talk to backend server.

If you divide the work this way, you can define a separate "-ds.xml" (just like defining a data source in JBoss) to instantiate your Resource Adapter. This file would contain the credentials you are looking for.  Writing a JEE connector can be daunting, but we made this process simpler, we give all the base classes you need to implement a JEE connector. For example, take look at our "connector-file" to see how simple this can be. I gurantee, this is not much more work than you already did. Just setting up a build process to to produce a "rar" can be tedious.

A JBoss login module comes into picture only when *you* want to authenticate the user in your layer, than letting your back end server handling it based on the passed in credentails. Even in this scenrio, JBoss provides better alternatives.

If you are doing this per user login to control the secuirty of the data from back end, then you should look into "data entitlements"

Hope this helps.

Ramesh..

[ftg314159]

Hi Charlie,

I'm not quite up to speed on what you're doing here, but I'm guessing that you need access to credentials the user has supplied to JBoss in order to connect to NOMAD on the back-end.  The Resource Adapter should give you what you need, read on ....

The EJB spec does its best to hide any real credentials from you.  We can mail offline about JAAS, but basically the client uses JAAS to solicit credentials from the user which are stored in a Subject.  JAAS is not a distributed protocol, and there is no standard for EJB clients and servers using JAAS in this way.  It is vendor-specific, and there is no requirement that JAAS or its constructs be used between client and server.

The EJB container is responsible for converting whatever credentials the client supplied to a mythical synthetic Principal.  This Principal has no reality other than being able to ask the container whether it can act in certain roles or not.

However, RAs need to access the original credentials in order to be able to effect logins to their associated back-end services, so the JCA SPI provides for the container to give you a JAAS Subject containing whatever came up.  You're still somewhat at the mercy of whatever client-side (and in the JBoss case, server-side) JAAS processing did - they may have converted a userid/password to some other form, such as a certificate, but with a little cooperation from the JBoss sysadmin you can make sure that a userid and password supplied by the client show up in the Subject that will be given to your RA.

Specifically, the JBoss use of JAAS on the client and server sides for a userid/password model has the client just shove these into a Subject that is passed up to the server and validated there by appluying the JAAS login module concept in reverse: the server-side module gets the saved credentials (rather than prompting the user for them), and validates them in any one of a number of ways, from a simple flat file to a JDBC database or an LDAP server.  But I'll bet that the Subject your RA is given contains what came up from the client (userid and password) on JBoss, and that's how you get what you need.  You shouldn't need to try to subvert connection parameters.

[chazware]

Thanks Frank.  I will send some details to you off line, so we can get to a solution.

It sounds like I need to create an RA, which I was tring to avoid.

Maybe I can use the RA Teiid's JDBC translators use.  But to do that I may need to change direction slightly to have my translator be a subclass of the Teiid base JDBC translator.  I probably also need to create a login module that adds the backend server U/P as a Principal so I can retrieve it.

[rareddy]

Maybe I can use the RA Teiid's JDBC translators use.  But to do that I may need to change direction slightly to have my translator be a subclass of the Teiid base JDBC translator.  I probably also need to create a login module that adds the backend server U/P as a Principal so I can retrieve it.

Yes, you can extend the JDBCExecutionFactory and override the capabilities methods to suit your needs, if you are working with a relational source.

For JDBC, Teiid uses the data sources supplied through JBoss AS as the RA, so Teiid does not directly supply and RA for this. Creating a separate login module for the RA and having it use it though Teiid is something we have not flush it though an example, however that is the intended direction to replace the "trusted payload" feature from prior Teiid releases. If you are taking this route, let us know how this works out for you or write WIKI how to, so that we can share with other users who may be looking at similar issue