Security

[dturanski]

Resolves #8 .

This actually works with PCC. If you follow the instructions for creating the service and service key. Then

$ cf service-key cloudcache my-service-key
Getting key my-service-key for service instance cloudcache as ...

{
 "locators": [
  "10.0.16.9[55221]",
  "10.0.16.11[55221]",
  "10.0.16.10[55221]"
 ],
 "urls": {
  "gfsh": "http://.../gemfire/v1",
  "pulse": "http://.../pulse"
 },
 "users": [
  {
   "password": "..",
   "username": "cluster_operator"
  },
  {
   "password": "..",
   "username": "developer"
  }
 ]
}

then create a stream:

dataflow:>stream create --name stocks --definition "http --port=9090 --security.basic.enabled=false  | gemfire --username=developer --password=<service-key-password>  --json=true --regionName=Stocks --keyExpression=payload.getField('symbol') --connect-type=locator --host-addresses=<service-key-locators>" --deploy

[sabbyanandan]

@jxblum: When you get a chance, it'd be great if you can review and give us feedback.

[jxblum]

Eventually, the new Spring Boot Data GemFire/Geode (SBDG^2) project (@ https://github.com/spring-projects/spring-boot-data-geode) will contain auto-configuration support to automatically configure your Spring Boot (Spring Cloud Data Flow or Spring Session) client applications to connect securely to an existing GemFire cluster (sink) without any additional effort by the user simply by annotating your Spring Boot client applications with SDG's @EnableSecurity annotation.

First, I needed to build out the "supporting" (Security) infrastructure in SDG^2 before I could get the bits in SBDG going. I have already documented both the server and the client (new) Security configuration using the new SDG Annotation-based configuration model in SDG's Reference Guide here... https://docs.spring.io/spring-data/gemfire/docs/current/reference/html/#bootstrap-annotation-config-security.

I apologize this has taken so long, but it will be much simpler going forward, I promise.

Today, if user created a Spring Boot (Cloud Data Flow or Spring Session) application and wanted/needed to secure it, s/he would annotate his/her Spring Boot (client) application like so (applying both SDG's ClientCacheApplication and @EnableSecurity annotations to her @SpringBootApplication annotated class)...

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

Then, the user would create an application.properties file like so...

spring.data.gemfire.security.username = cluster_operator
spring.data.gemfire.security.password = <enter-password>

And then the application would connect to the GemFire cluster (sink), whether that is PCC or a standalone GemFire cluster, securely.

FYI, I spoke with the PCC Toronto team last week while in Toronto for the SpringOne Preview, and for the Spring Boot Data GemFire/Geode Security auto-configuration bit, I asked them to add "Roles" to the PCC provided users (e.g. "cluster_operator", "developer") so that SBDG application does not need to "lookup" the appropriate user based on username, but can do so based on the "Role", which is better since SDG/SBDG needs a user with admin roles to do the "Cluster Configuration Push" (also a new feature).

Once the PCC team adds that, and once I get the SBDG^2 project auto-config up and running, then users will no longer need to supply credentials since that happens when their Space/Org and services are assigned (granted) for their Spring Boot apps they plan to deploy to PCF. So effectively, the Spring Boot application.properties file shown above goes away and all the user need do is annotate his/her Spring Boot client application class with SDG's @EnableSecurity annotation, and the user is done!

Outside of PCF though, a user will still need to supply the username/password as shown above, that that is pretty darn simple to do.

Thanks for you continued patience.

Let me know if you have additional questions.

[sobychacko]

Looks good. Polished the PR, squashed the commits and merged.