Looking at the geode implementation for Calcite it appears that those options aren't in there by default. That doesn't mean it won't work it's just that you would need to tell geode those details outside the scope of the calcite driver.
Note: I haven't tried this with calcite but should work based on my knowledge of Geode and generic applications. 1. Geode has a plugin architecture for security so your application needs an implementation for creating credentials. Take this as an example: https://github.com/Pivotal-Field-Engineering/pivotal-gemfire-ldap/blob/master/src/main/java/io/pivotal/gemfire/ldap/UserPasswordAuthInit.java Just compile the code and put it in the client classpath. 2. Create a gfsecurity.properties file and put in the current working directory and Geode will automatically pick it up. The order where Geode will look is current working dir, user.home and classpath. For a reference, you can start with this https://github.com/Pivotal-Field-Engineering/pivotal-gemfire-ldap/blob/master/src/test/resources/gfsecurity-locator.properties NOTE that file has more then what a client needs. - Doesn't need security-peer-auth-init and security-manager If you want to put the gfsecurity.properties file in another location you can always set a property to tell Geode where that file is located. Example: java ... -DgemfireSecurityPropertyFile=/wherever/the/file/is/security.properties ... Regards, Charlie - https://geode.apache.org/docs/guide/16/reference/topics/gemfire_properties.html - https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/distributed/DistributedSystem.java#L620 On Tue, Oct 16, 2018 at 3:36 AM aashish choudhary < [email protected]> wrote: > Thanks John and Charlie for your inputs. So if I were to connect to a > secure geode cluster by giving locator host and port in model.json as per > the calcite geode connector documentation how do I pass on the > security-username and password? > > Example model.json given below. > > { "version": "1.0", "defaultSchema": "geode", "schemas": [ { "name": > "geode_raw", "type": "custom", "factory": > "org.apache.calcite.adapter.geode.rel.GeodeSchemaFactory", "operand": { > "locatorHost": "localhost", "locatorPort": "10334", "regions": "Zips", > "pdxSerializablePackagePath": ".*" } } ] } > > Thanks, > Ashish > > On Sat, Oct 13, 2018, 4:58 AM Charlie Black <[email protected]> wrote: > >> From a Geode perspective, Calcite is just another application. So any >> data operations will be covered by the Geode Role-Based access control. >> >> As for LDAP - some commercial customers use this implementation which >> extends Shiro. >> https://github.com/Pivotal-Field-Engineering/pivotal-gemfire-ldap >> Hopefully the instructions on the git repo are good enough. >> >> I know it says GemFire - but it will plug right in since GemFire is the >> commercially supported version of Geode. Just change up the >> Gradle dependencies from GemFire to Geode. Maybe one day I will have to >> do what John did with Spring Data Geode/GemFire. >> >> Regards, >> >> Charlie >> >> >> >> On Fri, Oct 12, 2018 at 11:15 AM John Blum <[email protected]> wrote: >> >>> Hi Ashish- >>> >>> I am not certain how or if Christian tied the Apache Calcite based SQL >>> interface into Geode's security model/framework, but rather than >>> implementing your own SecurityManager interface [1], I would highly >>> recommend you consider using Apache Geode's, Apache Shiro [2] integration. >>> >>> Unfortunately, the Geode/Shiro integration is not well documented in the >>> Apache Geode documentation [3], but it is there none-the-less. >>> >>> I have written about this in a *Spring* context and how *Spring Data >>> for Apache Geode* along with *Spring Boot for Apache Geode* supports >>> this combination (primarily through configuration). >>> >>> See my blog [4]. >>> >>> The example code for this blog is here [5]. >>> >>> Note that, Apache Shiro has good integration support for MS Active >>> Directory, or just simply LDAP in general. In much the same way as Apache >>> Tomcat, Shiro integrates with different backing stores using Realms [6] >>> (and Javadoc [7]; see sub-packages, e.g. o.a.s.realm.activedirectory, >>> o.a.s.realm.ldap, etc). >>> >>> SDG doc on Security [8]. >>> SBDG doc on Security [9]. >>> >>> Hope this helps. >>> >>> -John >>> >>> >>> [1] >>> http://geode.apache.org/releases/latest/javadoc/org/apache/geode/security/SecurityManager.html >>> [2] https://shiro.apache.org/index.html >>> [3] http://geode.apache.org/docs/guide/17/about_geode.html >>> [4] >>> https://spring.io/blog/2016/11/10/spring-data-geode-1-0-0-incubating-release-released >>> [5] >>> https://github.com/jxblum/contacts-application/tree/master/security-example/src/test/java/example/app/geode/security >>> [6] https://shiro.apache.org/realm.html >>> [7] >>> https://shiro.apache.org/static/1.3.2/apidocs/org/apache/shiro/realm/package-summary.html >>> [8] >>> https://docs.spring.io/spring-data/geode/docs/current/reference/html/#bootstrap-annotation-config-security >>> [9] >>> https://docs.spring.io/autorepo/docs/spring-boot-data-geode-build/1.0.0.BUILD-SNAPSHOT/reference/htmlsingle/#geode-security >>> >>> >>> On Fri, Oct 12, 2018 at 6:45 AM, aashish choudhary < >>> [email protected]> wrote: >>> >>>> Hi, >>>> >>>> We are trying to leverage Apache calcite geode connector for Unified >>>> sql access. I have been reading blogs around it created by Christian Tzolov >>>> but not sure if it supports security-manager implementation of geode. Can >>>> this be integrated with Active directory/LDAP for authentication purposes?. >>>> >>>> Are there any success stories with this connector? >>>> >>>> Thanks, >>>> Ashish >>>> >>> >>> >>> >>> -- >>> -John >>> john.blum10101 (skype) >>> >> -- >> [email protected] | +1.858.480.9722 <(858)%20480-9722> >> Principal Realtime Data Engineer >> > -- [email protected] | +1.858.480.9722 Principal Realtime Data Engineer
