Let's try this again...

If you are using *Spring*, and specifically *Spring Data for Apache Geode*,
you don't have to worry about implementing any Geode specific interfaces to
pass credentials.

You can simply do this...

https://docs.spring.io/spring-data/geode/docs/current/reference/html/#bootstrap-annotation-config-security-client

In a nutshell...

@SpringBootApplication
@ClientCacheApplication
@EnableSecurity
class ClientCacheSpringBootApplication {
    ...
}

And then, simply put your username/password in a Spring Boot
application.properties file...

#application.properties

spring.data.gemfire.security.username=YourUsername
spring.data.gemfire.security.password=YourPassword

Easy!

If you are using Spring Boot for Apache Geode, it is even easier.  You only
need specify the username/password in application.properties since Security
is auto-configured by default.

See here:
https://docs.spring.io/autorepo/docs/spring-boot-data-geode-build/1.0.0.BUILD-SNAPSHOT/reference/htmlsingle/#geode-security-auth-clients-non-managed

Cheers,
John



On Tue, Oct 16, 2018 at 10:45 AM, John Blum <[email protected]> wrote:

> If you are using Spring, and specifically Spring Data for Apache Geode,
> you don't have to worry implementing any Geode specific interfaces to pass
> credentials.
>
> On Tue, Oct 16, 2018 at 9:29 AM, Charlie Black <[email protected]> wrote:
>
>> 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/pivota
>>    l-gemfire-ldap/blob/master/src/main/java/io/pivotal/
>>    gemfire/ldap/UserPasswordAuthInit.java
>>    
>> <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/Pivota
>>    l-Field-Engineering/pivotal-gemfire-ldap/blob/master/src/
>>    test/resources/gfsecurity-locator.properties
>>    
>> <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/gemf
>>    ire_properties.html
>>    - https://github.com/apache/geode/blob/develop/geode-core/src/
>>    main/java/org/apache/geode/distributed/DistributedSystem.java#L620
>>    
>> <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.ge
>>> ode.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-Fi
>>>> eld-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/mast
>>>>> er/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
>>
>
>
>
> --
> -John
> john.blum10101 (skype)
>



-- 
-John
john.blum10101 (skype)

Reply via email to