May 2019 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIIDSB-89) Unable to run -release, errors on performing javadocs

by Van Halbert (Jira)

[ https://issues.jboss.org/browse/TEIIDSB-89?page=com.atlassian.jira.plugin... ] Van Halbert updated TEIIDSB-89: ------------------------------- Git Pull Request: https://github.com/teiid/teiid-spring-boot/pull/89 > Unable to run -release, errors on performing javadocs > ----------------------------------------------------- > > Key: TEIIDSB-89 > URL: https://issues.jboss.org/browse/TEIIDSB-89 > Project: Teiid Spring Boot > Issue Type: Bug > Components: core > Affects Versions: 1.1.0 > Reporter: Van Halbert > Assignee: Van Halbert > Priority: Major > > Unable to run -release due to java doc errors, incorrect @param's defined. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-89) Unable to run -release, errors on performing javadocs

by Van Halbert (Jira)

[ https://issues.jboss.org/browse/TEIIDSB-89?page=com.atlassian.jira.plugin... ] Work on TEIIDSB-89 stopped by Van Halbert. ------------------------------------------ > Unable to run -release, errors on performing javadocs > ----------------------------------------------------- > > Key: TEIIDSB-89 > URL: https://issues.jboss.org/browse/TEIIDSB-89 > Project: Teiid Spring Boot > Issue Type: Bug > Components: core > Affects Versions: 1.1.0 > Reporter: Van Halbert > Assignee: Van Halbert > Priority: Major > > Unable to run -release due to java doc errors, incorrect @param's defined. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-89) Unable to run -release, errors on performing javadocs

by Van Halbert (Jira)

[ https://issues.jboss.org/browse/TEIIDSB-89?page=com.atlassian.jira.plugin... ] Work on TEIIDSB-89 started by Van Halbert. ------------------------------------------ > Unable to run -release, errors on performing javadocs > ----------------------------------------------------- > > Key: TEIIDSB-89 > URL: https://issues.jboss.org/browse/TEIIDSB-89 > Project: Teiid Spring Boot > Issue Type: Bug > Components: core > Affects Versions: 1.1.0 > Reporter: Van Halbert > Assignee: Van Halbert > Priority: Major > > Unable to run -release due to java doc errors, incorrect @param's defined. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-89) Unable to run -release, errors on performing javadocs

by Van Halbert (Jira)

Van Halbert created TEIIDSB-89: ---------------------------------- Summary: Unable to run -release, errors on performing javadocs Key: TEIIDSB-89 URL: https://issues.jboss.org/browse/TEIIDSB-89 Project: Teiid Spring Boot Issue Type: Bug Components: core Affects Versions: 1.1.0 Reporter: Van Halbert Assignee: Van Halbert Unable to run -release due to java doc errors, incorrect @param's defined. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-86) Plans for secure socket transports

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIIDSB-86?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIIDSB-86. ----------------------------------- Resolution: Done After making a full assessment, the recommendation is to: If end-to-end (internal and external) is needed, offer an option for 1-way secure transports using the service generated certificate. External exposure with a loadbalancer, which works for both transports with or without ssl. At an even later time, if secure external only is needed, we could offer an option for 1-way secure transports using a stunnel with external access provided via routes - but of course that requires that clients use a stunnel client as well. > Plans for secure socket transports > ---------------------------------- > > Key: TEIIDSB-86 > URL: https://issues.jboss.org/browse/TEIIDSB-86 > Project: Teiid Spring Boot > Issue Type: Quality Risk > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 1.1.0 > > > The Teiid Spring Boot configuration allows for only non-secured pg / JDBC socket transports. For external client scenarios and even for varying degrees of compliance with intra-cluster traffic, a secure layer may be required. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-86) Plans for secure socket transports

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIIDSB-86?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIIDSB-86: --------------------------------------- I took some time to investigate moving Teiid JDBC to websockets (which could directly use a route) as there is a netty stack that's available for that. The short answer is that it's not an easy drop in - at least a couple of days of effort. We need to add websocket client support to the driver via Netty or https://github.com/TooTallNate/Java-WebSocket and the related server handling into the pipeline. We need additional encode/decode support to take incoming bytebuffer messages and convert to binary websocket messages (there may be other steps, but that is as far as I got). On the client side we have to bridge between the websocket onMessage/send and inputstream/outputstream logic or completely re-implement the OioObjectChannel as a websocket version. Also having our protocol send the handshake from the server side initially is a little awkward. > Plans for secure socket transports > ---------------------------------- > > Key: TEIIDSB-86 > URL: https://issues.jboss.org/browse/TEIIDSB-86 > Project: Teiid Spring Boot > Issue Type: Quality Risk > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 1.1.0 > > > The Teiid Spring Boot configuration allows for only non-secured pg / JDBC socket transports. For external client scenarios and even for varying degrees of compliance with intra-cluster traffic, a secure layer may be required. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5734) Planning errors with masking due to unaliased column references

by RH Bugzilla Integration (Jira)

[ https://issues.jboss.org/browse/TEIID-5734?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-5734: ------------------------------------------------ jolee(a)redhat.com changed the Status of [bug 1706132|https://bugzilla.redhat.com/show_bug.cgi?id=1706132] from NEW to MODIFIED > Planning errors with masking due to unaliased column references > --------------------------------------------------------------- > > Key: TEIID-5734 > URL: https://issues.jboss.org/browse/TEIID-5734 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Critical > Fix For: 12.2, 11.2.3, 12.1.2 > > > The ColumnMaskingHelper is creating expressions using the unaliased source name. This implicitly is relying on other logic, such as the raising of an access node to compensate for that. If however a view layer with masking is used that has no access nodes or cannot be removed, then exceptions will occur if it appears in the user query aliased and with constructs above, such as an order by. > For example with the vdb: > {code} > <?xml version="1.0" encoding="UTF-8" standalone="no"?> > <vdb name="odatacm" version="1"> > <description>Test column masking for Odata </description> > <property name="validationDateTime" value="Thu May 02 14:13:21 CDT 2019"/> > <property name="validationVersion" value="8.12.13"/> > <model name="vw" type="VIRTUAL"> > <metadata type="DDL"><![CDATA[ > CREATE VIEW employee ( > id integer, > name string, > taxid string, > taxid_cd string, > CONSTRAINT pk_id PRIMARY KEY(id) > ) OPTIONS(UPDATABLE 'TRUE') > AS > SELECT > 1 AS id, 'Debbie' AS name, '123456789' AS taxid, 'SSN' AS taxid_cd > UNION > SELECT > 2 AS id, 'Mide' AS name, '234567891' AS taxid, 'FED' AS taxid_cd > UNION > SELECT > 3 AS id, 'DJS' AS name, '345678912' AS taxid, 'FED' AS taxid_cd > UNION > SELECT > 4 AS id, 'Joe' AS name, '456789123' AS taxid, 'SSN' AS taxid_cd; > ]]></metadata> > </model> > <data-role allow-create-temporary-tables="false" any-authenticated="true" grant-all="false" name="Data Role 1"> > <description/> > <permission> > <resource-name>vw.employee.taxid</resource-name> > <condition>vw.employee.id>2</condition> > <mask order="0">'Blocked'</mask> > </permission> > <permission> > <resource-name>vw</resource-name> > <allow-create>false</allow-create> > <allow-read>true</allow-read> > <allow-update>false</allow-update> > <allow-delete>false</allow-delete> > <allow-execute>false</allow-execute> > <allow-alter>false</allow-alter> > </permission> > <permission> > <resource-name>sysadmin</resource-name> > <allow-create>false</allow-create> > <allow-read>false</allow-read> > <allow-update>false</allow-update> > <allow-delete>false</allow-delete> > <allow-execute>false</allow-execute> > <allow-alter>false</allow-alter> > </permission> > </data-role> > </vdb> > {code} > and the query "select * from employee as e order by id" is issued, then an exception will be returned: > TEIID30259 Cannot introduce new expressions [vw.employee.id] in duplicate removal > Which is a safe guard to prevent further planning errors - note the unaliased / fully qualified name in the exception message. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-86) Plans for secure socket transports

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIIDSB-86?page=com.atlassian.jira.plugin... ] Steven Hawkins edited comment on TEIIDSB-86 at 5/14/19 12:44 PM: ----------------------------------------------------------------- an sni passthrough route works as expected, with the caveat that using anonymous ssl seems problematic. Using a static security.setproperty to update the disabled did not work - it does work in the same spring boot app locally. That's something we can look at later. This is where things stand without utilizing a stunnel: ||Secure Transport Options||Teiid JDBC||PG|| |End-to-end (internal and external) - Need to allow ssl configuration with either a user-provided cert or a generated one|passthrough route or loadbalancer for external|loadbalancer for external| |Secure External and Clear Internal - Same as above for external - need to allow ssl configuration with either a user-provided cert or a generated one|Would require separate transports|Would require separate transports or an update to the logic requiring a secure connection based upon internal vs. external traffic| |Clear|loadbalancer for external|loadbalancer for external| Based upon all of this we should probably offer the following: * clear transports (current), or 1-way secure transports using the service generated certificate (I'll validate that this works as expected) * optional external exposure with a loadbalancer, which works for both transports with or without ssl. It could be documented how to utilize a router for secure jdbc as well. Two-way authentication and user supplied certs could be considered later. Going the stunnel route looks like: ||Secure Transport Options||Teiid JDBC||PG|| |End-to-end (internal and external) - Need to allow ssl configuration with either a self-signed or a generated one|stunnel for external, internal clients (other pods) need to be configured with an appropriate truststore|same as jdbc, with the caveat that pg would effectively be double encrypted unless more logic were added about when to secure| |Secure External and Clear Internal|stunnel for external|stunnel for external| |Clear|loadbalancer for external|loadbalancer for external| was (Author: shawkins): an sni passthrough route works as expected, with the caveat that using anonymous ssl seems problematic. Using a static security.setproperty to update the disabled did not work - it does work in the same spring boot app locally. That's something we can look at later. This is where things stand: ||Secure Transport Options||Teiid JDBC||PG|| |End-to-end (internal and external) - Need to allow ssl configuration with either a user-provided cert or a generated one|passthrough route or loadbalancer for external|loadbalancer for external| |Secure External and Clear Internal - Same as above for external - need to allow ssl configuration with either a user-provided cert or a generated one|Would require separate transports|Would require separate transports or an update to the logic requiring a secure connection based upon internal vs. external traffic| |Clear|loadbalancer for external|loadbalancer for external| Based upon all of this we should probably offer the following: * clear transports (current), or 1-way secure transports using the service generated certificate (I'll validate that this works as expected) * optional external exposure with a loadbalancer, which works for both transports with or without ssl. It could be documented how to utilize a router for secure jdbc as well. Two-way authentication and user supplied certs could be considered later. > Plans for secure socket transports > ---------------------------------- > > Key: TEIIDSB-86 > URL: https://issues.jboss.org/browse/TEIIDSB-86 > Project: Teiid Spring Boot > Issue Type: Quality Risk > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 1.1.0 > > > The Teiid Spring Boot configuration allows for only non-secured pg / JDBC socket transports. For external client scenarios and even for varying degrees of compliance with intra-cluster traffic, a secure layer may be required. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-86) Plans for secure socket transports

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIIDSB-86?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIIDSB-86: --------------------------------------- > 1-way secure transports using the service generated certificate While this simplifies the creation of keystore, it is cumbersome for intra and especially external cluster clients. Internal generally require an init container to prep the service.ca mounted file. External clients still require some mechanism to export the public key(s). The only option to externalize this is to use stunnels so that the ssl configuration is defined on the stunnel route. > Plans for secure socket transports > ---------------------------------- > > Key: TEIIDSB-86 > URL: https://issues.jboss.org/browse/TEIIDSB-86 > Project: Teiid Spring Boot > Issue Type: Quality Risk > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 1.1.0 > > > The Teiid Spring Boot configuration allows for only non-secured pg / JDBC socket transports. For external client scenarios and even for varying degrees of compliance with intra-cluster traffic, a secure layer may be required. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-86) Plans for secure socket transports

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIIDSB-86?page=com.atlassian.jira.plugin... ] Steven Hawkins edited comment on TEIIDSB-86 at 5/14/19 10:14 AM: ----------------------------------------------------------------- Another approach for external pg transport security is the use of a stunnel - http://cpitman.github.io/openshift/tcp/networking/2016/12/28/stunnel-and-... - which can be combined with the service certificate generation linked above, rather than his example that shows a self-signed certificate. The upside is it allows a route to be used. The downside being the requirement of running a client stunnel instance. You'd also have a stunnel server instance along side every Teiid instance. And this still exposes an intra-cluster unsecured host/port - so we'd either have to double encrypt (at the stunnel level and at the pg protocol level) or make the requirement for a secure pg transport more flexible. Of course since we have control over the teiid jdbc side we could just do http/https ourselves there and further simplify things. was (Author: shawkins): The only approach for external pg transport security is the use of a stunnel - http://cpitman.github.io/openshift/tcp/networking/2016/12/28/stunnel-and-... - which can be combined with the service certificate generation linked above, rather than his example that shows a self-signed certificate. The downside being the requirement of running a client stunnel instance. You'd also have a stunnel server instance along side every Teiid instance. And this still exposes an intra-cluster unsecured host/port - so we'd either have to double encrypt (at the stunnel level and at the pg protocol level) or make the requirement for a secure pg transport more flexible. Of course since we have control over the teiid jdbc side we could just do http/https ourselves there and further simplify things. > Plans for secure socket transports > ---------------------------------- > > Key: TEIIDSB-86 > URL: https://issues.jboss.org/browse/TEIIDSB-86 > Project: Teiid Spring Boot > Issue Type: Quality Risk > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 1.1.0 > > > The Teiid Spring Boot configuration allows for only non-secured pg / JDBC socket transports. For external client scenarios and even for varying degrees of compliance with intra-cluster traffic, a secure layer may be required. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues May 2019