So that would be a great chat from the get-go - and here it is:
Here's the transcript of our conversation:
RVB: 00:02.575 Hello, everyone. My name is Rik, Rik Van Bruggen from Neo Technology and here we are again recording another podcast episode. Today I'm joined by I think it's the first Canadian that I have on this podcast, Dave Bennett from Nulli. Hi, Dave.
DB: 00:17.431 Hey, Rik. Thanks for having me. This is great. Good to be the first Canadian [chuckles].
RVB: 00:22.501 Exactly, thank you for joining me. You're in Calgary, right?
DB: 00:26.851 I am, yeah. Calgary, Alberta, Canada. So situated sort of west side of Canada on the Eastern slopes of the Rocky Mountains.
RVB: 00:36.574 Everyone knows the Calgary Olympics, or at least for my age. So Dave, maybe you can just quickly introduce yourself to our audience here. Who are you? What do you do? What's your relationship to the wonderful world of graphs?
DB: 00:52.011 Yeah, absolutely. My name's Dave Bennett, and I started out as a HR payroll benefits developer many, many years ago and that quickly morphed into identity and access management world. And through many acquisitions and different paths taken, I ended up doing implementation ForgeRock IAM platform. And anyways, one day it struck me that there was evolving NoSQL options, and I caught onto the graph and thought the graph was really the most applicable NoSQL database for identity management applications.
RVB: 01:42.716 Well, you know this is a topic that's close to my heart, right? I spent at least ten years in that industry myself working for Novell, and Imprivata, and Courion, so we have a lot in common there, I think [chuckles].
DB: 01:56.215 Oh yeah, we do. When I reached out to you a few years ago I was immediately like, "Wow, this is a small world stuff."
RVB: 02:05.050 Yes it is, absolutely. So how does the world of identity and access management-- I'm loosing my tongue here. How does that relate to graphs, you think? Why is it so applicable?
DB: 02:18.827 Well, I think we're always after how things are related to each other and more and more with the identity being so important and intrical to decision making. Having more relationship based data, and being able to quickly navigate it, allows us to make informed decisions about things we couldn't necessarily do before. And so I think being able to maintain data in the graph, and then query it for authorization decisions, in particular, is very powerful in terms of world identity management. It's-- sorry.
RVB: 03:06.419 No, no, no.
DB: 03:08.081 Go ahead [chuckles]
RVB: 03:09.998 Sorry about that, Dave. But how does it fit into things like ForgeRock and stuff like that? I've seen some of your presentations from GraphConnect, actually. There's a clear link between some of those IAM products, right?
DB: 03:24.911 Well, there is. Yeah. So ForgeRock platform supports, there's about four main products. There's the open DJ directory server, which is a primary identity store for just core identity. And then there's the OpenAM product, which is a access management product. So we're doing all kinds of federated access, you name it. And OpenIDM product, which is for generally provisioning access and workflows, and then there's the OpenIG gateway. And all of these four products work in conjunction with one another for solving identity-related problems. But the one core they have - one thing in the core at all of them - is the extensibility. They're all very open to extension. And they're all Java-based applications. So being able to write plugins that run inside the servers themselves that connect to Neo is very, very easy. It's a way of quickly extending what the platform is capable of doing from a graph perspective.
RVB: 04:41.374 Can you make ForgeRock actually make authentication authorization decisions based on the Neo4j graphs, or is it--?
DB: 04:50.927 Oh yeah.
RVB: 04:51.938 Oh, you can? Okay.
DB: 04:53.097 Oh definitely. Definitely. So the ForgeRock OpenAM platform there's a-- basically the authentication and authorization pieces are all extensible - very easily writing your own Java plugins. As well if you don't want to write native Java stuff, you can write scripted connectors in JavaScript and Groovy. So with the new Bolt protocol, you could easily use JavaScript scripted connector if you wanted to and use that to write a policy plugin. We actually have a plugin that we created - a policy condition plugin - that accepts basically a cypher query, the authenticated user, and the requested resource as parameters, and we'll go make that cypher query over the rest endpoint against a graph. And we're rewriting that to use Bolt right now.
RVB: 06:02.908 And does that then allow you to do more complex authorization decisions? Or is that the main advantage there, or is--?
DB: 06:11.171 That is definitely the goal is to basically use relationships and make more complex decisions. And you can do things in a graph that aren't very easily attainable in a traditional SQL database or LDAP, right? An end depth query is achievable in SQL. But you end up with these massive self-joints, which quickly lose steam and fall on their face, whereas those are very simple - even from cypher perspective - queries, right? And then LDAP, that stuff is, again, also achievable. It becomes successive subsequent queries with lots of round trips and lots of post processing to follow all the relationships. So yeah, it provides a certain level of flexibility. And where there's complexity, you can get past complexity with the graph.
RVB: 07:21.094 So I think you're already answering my follow on questions there a little bit, which is, what's so cool about graphs in this context, and why is it so powerful? Is it about the complexity flexibility that I'm hearing, or are there any other topics that you think are more important?
DB: 07:38.436 Oh no. I think it is definitely about the complexity and flexibility. And where we are going with identity management, and the path we're on right now, we are-- especially with the Internet of things. I mean, this stuff's all sorting itself out right now, and it's still early days. But the one thing I think we can all agree on is the complexity of things and having to share data, or pieces of data, from one identity to another identity. Every connected device has its own identity. And there're many, many interested parties that are after that data. So securing that data is going to be essential, and I think the way of securing that data is going to be founded upon a myriad of relationships that are going to have to be able to be digested in a meaningful time frame. I think the graph is going to be critical to solving those problems.
RVB: 08:43.730 Absolutely. Again, you're already answering my [chuckles] final question, so to speak, which is, where is this thing going? These evolutions that we're seeing within the things and stuff like that, that just begs the question - how do I manage access at scale in real time with a very complex network of devices, people, all of those things? Right?
DB: 09:12.458 Exactly. I think where we're going is more complex relationships than we've ever deemed imaginable before. And the way we're going to be able to explore and continue to make sense of the stuff - the only way - is through graph database. And so then the graph database by itself though can represent all these things, but it still has to be maintained and it still has then be used by something to enforce policy. And that's where coupling it with the ForgeRock platform, in my mind, makes the most sense. It's taking two products that, by themselves, are great and great at doing what they do and making something even better at the end of the day through both product's extensibility, right?
RVB: 10:08.674 Absolutely.
DB: 10:09.057 The openness of the ForgeRock platform, and the ability now with the new transaction endpoint prior but now with the Bolt protocol, really made accessing graph data so easy.
RVB: 10:31.873 That's great to hear. And I think on that bombshell, I think we'll wrap up this episode of the podcast, Dave. I really want to thank you for coming online and speaking to us about that, and we'll put some more links to ForgeRock and also your talks about this, to work around this, on the blog post that we publish afterwards as well. So thanks a lot for doing that and all the best.
DB: 11:01.795 Thanks, Rik. Thank you for having me. I had a good time.
RVB: 11:04.810 Talk to you soon.
DB: 11:05.421 Take care.
RVB: 11:06.676 Bye.Subscribing to the podcast is easy: just add the rss feed or add us in iTunes! Hope you'll enjoy it!
All the best
Rik
No comments:
Post a Comment