Ping Identity

Robert MacDonald: Welcome to another IBA Friday. It's the IBA Friday before Halloween, so I don't normally look this cool. But today, for all of you, I decided I would wear one of my favorite-ist, yeah, is that the right word, costumes. I'm a shark today. Daddy Shark.

Javed Shah: I'm not noticing much of a difference, to be honest.

Robert MacDonald: Yeah. Thank you, buddy. And you're dressed up as always. Javed, you still have your usual Halloween costume on, it's good to see.

Javed Shah: No costume.

Robert MacDonald: All right, so today everybody we have an announcement this week. And for those of you that were paying attention or track those kinds of things, we announced our integration with Ping DaVinci, which is a new orchestration tool from Ping. And, we've done some work to integrate with that. And Javed is going to be amazing and show us all about that, right? Tell us a little bit about it first, then maybe show us how it works.

Javed Shah: Yeah, sure. So, it's a pretty cool flow-based orchestration platform. You can put things together. We're going to build a journey for users. For example, if you're looking to, I don't know, step a user up in their authentication journey, if they're coming in from an IP address that you suspect, you can actually set up the flow to look for the signal, which is the IP address in range and out of range. And then you can, if it is out of range, you can have a call-out to, let's say the 1KOSMOS authentication server for authenticating the user in case they're out of range. Things like that.

You can put your authentication journey together and calibrate the amount of friction you want to apply, how much flexibility you want to retain because the types of users coming in to authenticate might not all need that much friction. So it's a very nice way to, at run-time, size up the risk and present friction accordingly. Just sum it up that way. It's pretty neat. Most of the industry is heading that way anyway.

Robert MacDonald: Yeah. I mean, you've said those words a couple of times on these IBA Fridays talking about orchestration and journeys, right? So, it falls in line with what you've been saying for a while now.

Javed Shah: Yeah, absolutely. I think it's really important to stop statically defining and hard coding journeys together now. All are ready, right?

Robert MacDonald: Yeah, agreed. Yeah.

Javed Shah: All right, so let's-

Robert MacDonald: Too fragile, right? When you do it that way?

Javed Shah: Too fragile, too much change, high maintenance, all of that stuff, right? Okay, so I'm just going to share my desktop in one go here. You tell me if you are able to see the screen.

Robert MacDonald: We have a new connection 1KOSMOS connector.

Javed Shah: Yeah. Very nice. So, I have two videos. One of the first one, I'm just going to talk about how you set up the 1KOSMOS connector in the platform, in the DaVinci platform. And in the second video, I'll just show a demonstrated use for authentication, right? Keep it simple.

Robert MacDonald: Okay. Yeah, cool.

Javed Shah: Okay. So if I were just start this from the beginning here, let's play this. So, this is the login of DaVinci environments platform. You add connections this way, give it a name. So the whole idea is for the 1KOSMOS authorization server to be set up to receive those requests, those authentication requests be routed from someone trying to log into the Ping platform. Because the orchestrator wants the step-up to be redirected to the step-up provider, the provider needs to be configured here-

Robert MacDonald: Okay. Javed Shah: ... while you're seeing the screen, which is basically telling you, "Hey, use the following redirect URL." All it's really trying to say is, "This particular string, this redirect URL is the hook to combine the 1KOSMOS provider and the DaVinci platform together. I'll show you how." So this is the key basically that they will use to come back to the 1KOSMOS adminX platform, right? Here we say, "Oh, going really fast, let me slow it down." All we want to do is, well, if we are the authorization server, we are the provider of that higher assurance via step-up, then we need to know where the request is going to come from.

Robert MacDonald: Come from?

Javed Shah: Yeah.

Robert MacDonald: That makes sense.

Javed Shah: And where it's coming from is an OIDC application. That's the construct of how these things work. So, you tell us what OIDC applications you would like us to protect. You configure them in said way, right here, let's say. Click on that. Shows up a simple page, name the app, decide what grant type. Maybe, that's a little bit too technical, but there's different types of OAuth 2 grant flows.

Some are more secure, some are less. You will see here that we only support the most secure. Let's get to that right here. So we support authorization code and authorization code with the proof key code exchange. The pixie, which is for the mobile channels where you pass a nonce, that nonce must match for every authentication handle comes in to make sure that you're tightly binding the device, et cetera, et cetera. And of course, a somewhat lesser, but more important generally important, machine credential client credentials grant. Okay, big picture authorization code is a two-legged flow. I give you a code, you replay that code back to me. I know it was the code I generated, therefore I trust you. Very simple.

Robert MacDonald: Okay.

Javed Shah: So basically what's happening here is not only are we identifying who is or what is this OIDC application that we can expect requests, requests from for user authentication, we also know that we have to create a code for this particular entity and then that entity has to replay the code back to us to establish a tighter authentication journey. That's all what's going on here.

Robert MacDonald: Okay.

Javed Shah: When we pick that, you'll see that the redirect URL we had copied over from the DaVinci platform.

Robert MacDonald: DaVinci, yeah.

Javed Shah: That kind of is plugged in here and this is what kind of binds the two entities together to recognize each other, right?

Okay. So I should pause here and see if I can move this little bad boy over here. Yes. So while we are working on supporting custom OAuth 2 scopes, what we have here out of the box are simply profile, which means that this application is entitled to receiving user profile data. That's all what a scope implies. It just says, "Hey, you're defining this application. That's all well and good. You're telling me it's an auth code based flow. Fine. But after the authentication completes, would you like me to share something with this app for it to be a bit more useful for that application, decide what to do?" Yeah?

Robert MacDonald: Mm-hmm.

Javed Shah: So we are saying by default, we are going to say yes to three scopes profile, which is your user PII email, and the open ID is a special scope as per the spec that basically says, by the way, not only create an authorization grant via an access token, also package the PII in a special token called an identity token.

It's basically akin to a modern SAML almost where you're federating out. If you have the open ID checked, that scope checked, it federates out a special token called identity token that has only one purpose in life to assert PII claims for a user who has passed an authorization grant check.

Robert MacDonald: Got it.

Javed Shah: That's it. Okay then. So we have this application all done and dusted here. As soon as we identify what is the application that we can expect requests from, we are ready to go right back to the DaVinci platform. And something really quick happened here. So I think they're just simply- I think they require a test environment for...

Robert MacDonald: To make sure it works?

Javed Shah: Yeah. Require a test environment where they want to send that construct, that redirect to, and that's it. I believe that should be it. If I just fast track this a little bit. Yes.

Now while we did the redirect URI link up, we also have to match the client identification that the AdminX platform from 1KOSMOS created as an identifier. So basically identifying both by first name instead of just by redirect URI. All right, so this is good. I'm just going to kind of speed forward here. All good. There's a lot of information here.

Robert MacDonald: Mm-hmm.

Javed Shah: I'm not sure how much to describe given the time constraints we have, but this is basically just giving you some information about, well, what is this authorization server? What's the metadata for it? Where is it located? Those kinds of things.

All right. So way too much going on here. So this is just the configuration setup. I think what will be more interesting would be the next video, right?

Robert MacDonald: Okay.

Javed Shah: So are you able to see this second video? Are you able to see here the OID setup?

Robert MacDonald: I got it. Yeah. It says, "Create new flow."

Javed Shah: Yeah, so I think this is more interesting. The configuration part is fine. We kind of described high level why we need the configuration. And the rest of the video was about the actual step-by-step...

Robert MacDonald: How to set it up.

Javed Shah: [inaudible 00:09:42] the client ID secret, all of that good stuff.

Robert MacDonald: Yeah.

Javed Shah: But I think more fun would be possibly, "Hey, fine. You have a connector set up. Now show me how the flow based orchestrator works," right? So you just start with a blank flow, you call it something, whatever OIDC step up in the DaVinci platform.

This is exciting obviously, because this is a modern orchestration editor. That's pretty cool, right? Okay. So what they're looking to do here is they're saying I would like an HTTP connection - could be HTTPS as well.

Robert MacDonald: Okay.

Javed Shah: I would like an HTTP connection using the 1KOSMOS, and I'm not exactly tracking. Okay. What's being entered? Yeah, there you go. So we would like the HTTP connection and we would like it to be... Let me just go forward here. Yeah. We would like to invoke the 1KOSMOS step up connector over an HTTP connection.

Now you've already set up the connection, but you also want to identify- I think the way, and I'm no expert in the DaVinci platform, but I think the way you want to set up these connections is you want to identify what the trigger should be. I think that's what they're trying to do here. Apologize. It's kind of jumping all over the place, isn't it?

Robert MacDonald: No, no, no, no. I don't think- I mean...

Javed Shah: But it's something interesting I'll just talk about in a second here.

Robert MacDonald: Yeah.

Javed Shah: So this, I'll pause right here. So it's one thing to, obviously I create an OIDC application within 1KOSMOS to know who's going to be sending us a request, another thing to then drag that connector's configuration in line in the flow. But that doesn't answer that one final question, which is, "Well, how would you like Robert," the user, right, who's being stepped? "How would you like Robert to authenticate? What factors do you allow to permit?" Right? And I think the real beauty of the 1KOSMOS walk-through implementation for Step Up is that using the ACR claims as shown here in the video, you can specify what different factors and in what order you would like them to be presented.

Robert MacDonald: Oh.

Javed Shah: So this is really, really unique. We are not just limited to, "Hey, we step up users with OTP."

Robert MacDonald: Yep.

Javed Shah: Or it's not statically defined as, "Hey, we step up users with push notifications so they're [inaudible 00:12:10]or to the app." No. You can actually define as the OAuth 2 spec mentions. You can define, "Hey, what potential ACR factors would you like to?" And that's being shown here, which I thought was interesting.

Robert MacDonald: Okay. And that's the live ID push? OTP [inaudible 00:12:27]?

Javed Shah: Absolutely.

Robert MacDonald: Okay.

Javed Shah: Absolutely. If you have just live ID, then you know what you're expecting Robert to do.

Robert MacDonald: Yeah.

Javed Shah: You're expecting him to open up his phone and do a selfie.

Robert MacDonald: Yeah, that's right. Okay. That's cool. Yeah. Yeah.

Javed Shah: Exactly. So I think that's what's happening here. As you can see, the claims will be individually entered. So here an ACR claim will be entered, which is what, as you can see on the, they're literally doing that. They're entering the claims.

This is obviously an OAuth 2, an OIDC construct where you have to specify, "Well, what would you like to ask 1KOSMOS, the authorization server?" And that text over there is telling, basically sufficiently populating the request to say, "Ask the following."

Robert MacDonald: Okay.

Javed Shah: "Ask for the following factors." And this is pretty cool because once we are past this, which I would like to go to. Even a beautifully designed flow control orchestrator cannot escape a text area.

Robert MacDonald: Yeah, yeah. You got to do a [inaudible 00:13:26] little bit of coding.

Javed Shah: Yeah, just stuff in a hundred words worth of claims, no big deal.

Robert MacDonald: Absolutely.

Javed Shah: Okay, so this is done. I've already shown what an example of the said claim was. So I think we are good here. And then at that point, once the authentication is completed, I believe what they're trying to do here is just dump the returned information on a page for inspection.

Robert MacDonald: Okay.

Javed Shah: I believe is what's going to happen. Let's see, what does he pick here? I think he's going to pick something simple. It just output everything into a page.

Robert MacDonald: Okay.

Javed Shah: Yeah. There you go. Okay, so now we've saved the flow. This is pretty cool. At this point, I think they clicked on test somewhere. Did I miss it? Save successfully? Where is the next click coming from? There should be a test somewhere. Ah. Save and deploy. See that?

Robert MacDonald: Yeah, yeah, yeah, yeah.

Javed Shah: It's saying save it and then deploy it. As soon as you deploy it you see this URL here. It's basically taking you to the test environment that we identified earlier. And at this point, my developers see the way to try and sign in. Let's see. Authentication in progress here. We've received the OIDC request with appropriate-

Robert MacDonald: You can see the Block ID started to pop up now.

Javed Shah: ... appropriate ACR claims. Ah, this is interesting, right? We had asked for certain factors.

Robert MacDonald: Yeah.

Javed Shah: All of those factors are here. Okay? So let's see. If the user chooses to have a push sent to them. Well, a push has been sent to them. And I think this video just demonstrates that one thing for illustration obviously. And on the mobile phone, as long as they're saying yes, look, we have obviously the famous consent screen, the walkthrough consent screen.

We are telling you, "Well, we are sharing your information with this target application. We obviously, funnily named it OIDC Step-up. This could be whatever, relying party's name. And we say, "We need your permission to share the following bits of information over." So the scopes that we had- remember when we were setting up the OIDC app, we had a profile and an email scope?

Robert MacDonald: Yep.

Javed Shah: We are literally populating that screen with that information to confirm with the user-

Robert MacDonald: Got it.

Javed Shah: ... that it would like to approve.

Robert MacDonald: All right.

Javed Shah: As soon as that is done, we get that the session dump in line right here. Okay?

Robert MacDonald: And this is everything that it just pulled from the session?

Javed Shah: Absolutely. Because the 1KOSMOS server generated not just an access token, as we said earlier. Because the Open ID proof, Open ID scope was there as well. We also had to generate as per spec, the identity token called an ID token. You're seeing the [inaudible 00:15:59] 64 version of this obviously.

Robert MacDonald: Yeah.

Javed Shah: So yeah.

Robert MacDonald: We talked with that ID token when we were setting things up in terms of what are the three things that we want to pull. So that was...

Javed Shah: That was it, yeah.

Robert MacDonald: We also have the user data above there as well. So you can see all those things that we captured. See? I pay attention.

Javed Shah: Despite that shark costume, you're really [inaudible 00:16:19]. I'm surprised I'm able to pay attention. So yeah, all the claims are there, as usual as what you would expect. But I think the real power, obviously is twofold. One is that we integrate with the Ping.

Robert MacDonald: Yes.

Javed Shah: The Ping DaVinci marketplace. That's amazing, right?

Robert MacDonald: Yeah.

Javed Shah: Easy customer acquisition there. And secondly, there's so much flexibility built into the 1KOSMOS implementation where you can specify the factors you want the user to pick from. That's amazing. Because you can just ask for one, if it's a workforce use case, you just want to tie it down, fine. If not, if you want the users to have optionality, well, it's built into our implementation, right? That's pretty cool.

Robert MacDonald: Yeah. That's very cool.

Javed Shah: That's it. That was the video.

Robert MacDonald: Nice. So yeah, listen, that's all very exciting stuff. I know that you and the team have been pretty hard at work trying to get that up and running. It's exciting to see it live in production now. So you said that that was available up on the Ping's-

Javed Shah: It's up on the marketplace. Yep. It's all ready.

Robert MacDonald: Awesome. That's great. Javed, thanks for walking us through that. I appreciate it. And for everybody that stopped by today, thanks again. Happy Halloween.

Javed Shah: Happy Halloween. Yeah.

Robert MacDonald: In case it keeps been late, I'm wearing this because it's Halloween. It's a costume.

Javed Shah: Extra points for Robert.

Robert MacDonald: Yeah. Extra points today. So anyway, listen, we'll see you guys again in a couple weeks where we'll walk you through something else that's pretty cool.

Javed Shah: Yeah.

Robert MacDonald: Thanks everybody. Happy Halloween. See you again.

Javed Shah: Bye.