Defining Modern Identity and Access Management

Matt Egan:  Good morning. Hey, it's good to see people out here in the seats. I was a little bit concerned being the day after the party. Then I was a little bit concerned that maybe some of you guys would recognize me from the dance floor, but then on the dance floor I saw and I recognized a lot of these faces from the dance floor and so it's not as awkward anymore. 

Anyways, welcome out. Today, we're going to be going through, as the slide says, Defining Modern Identity and Access Management. My name is Matt Egan. I'm a Partner Solutions Technical Architect at Okta. This is actually my fifth Oktane. First one as an employee I've had four customer visits at two Oktane prior to becoming an employee. Then joining me later, actually replacing me later will be Suresh Kurra.

Before we jump into the meat of it, we do have the forward-looking statement. I'll give you guys a second to read this. Okay, we're done. Bottom line, there's forward-looking statements in this presentation. Don't use any of the data from this presentation to make financial decisions or investment decisions.

The agenda. Let's go through and talk about what we're going to talk about. I really struggled with this, what the best way to convey either the immense value that can be derived from Okta and our partnerships with various networking providers out there. It was difficult. What I'd love to do is sit down with each and every person in the crowd and talk about their specific problems and go through and talk about the solutions. We don't have that kind of time, so what we're going to do is go through and make sure we have a common understanding of the problem that we're trying to talk about here. 

We're going to share the Okta perspective on what the answers to that problem can be or should be, go through an overview of what those solutions are, and then I'm going to hand it over to Suresh where he's going to go through a customer-use case, which is a bit of a deep dive into their specific problem and how they went about solving that problem.

What is it? What is it we're talking about here and the problem associated with modern identity and access management? If you guys have looked at any of our white papers or solutions briefs, this will look a little bit familiar. It's kind of a common diagram we use to define and expose the problem. There's some common themes in here. Clearly, there's Okta. Because there's Okta, there's a user because we're an identity company. On the inside of this thing, or on the inside of the network, is an application data, a webservice, whatever it may be. What we're getting at here, the solution we're trying to solve, and I guess we didn't get into the synopsis of it, was we're trying to explain how with Okta you can get access to those old legacy ... Well, they don't have to be old, they can be new ... But these legacy on-premise applications that you have that are either not available over the internet or they're speaking an authentication protocol that Okta doesn't do natively. 

We have this, not necessarily apparent, but the thin, gray line that divides the two. What is it that's in that thin, gray line? That's really the problem that we're talking about. What is in this thin, gray line? What are the opportunities and problems there?

As I've gone through and looked at the various integrations that we have, I've boiled these down and I put them into two buckets. It's either a connections security thing, or it's an authentication translation problem that we're trying to solve in this thin, gray line. That was just boiling it down right to the nuts and bolts.

In this thin, gray line, what are we doing in those? As I said, we've got connection security. They can be something like a client VPN or a client less VPN that we need to authenticate an end-user to. In a more modern case, it could be something like connection security or an HTTP session that we're going to do an authentication before we allow access through to a downstream or an internal server, but we're going to do it on an HTTPS session, HTTP session basis. We do these things with partnerships at F5 with their big IP APM and Palo Alto Networks with their global protective product.

The other thing that we do there in that thin, gray line is what I'm referring to as authentication magic. That is something where we're taking the claims that Okta is sending in a SAML Assertion, extracting data from those, and doing something either KCD, Kerberos Constrained Delegation, where we take the data out of that SAML Assertion and exchange it for a Kerberos Ticket that we can then use to provide to a downstream application to do authentication. Or a very similar process, but instead of a Kerberos ticket, a certificate, and some of the other things that are useful in there is to do header manipulation where you can just straight extract the data from the SAML Assertion and insert it into an HTTP Header to a downstream system. Again, some of the partners that we have that solve those problems, F5 again and Citrix NetScaler. 

So what does this look like in practice and implementation? Again, there's lots of providers that can do this. I'm going to demonstrate what it looks like with Palo Alto. With Palo Alto Networks and their latest software release, they support SAML as a native authentication and so in their global protect configuration, you can have the SAML set up so that it is the authentication mechanism to connect to that gateway and the result is, for an end-user when they're using that client, that they get a very familiar Okta sign in page embedded into the global protect client. 

We can leverage the flexibility and power of Okta's sign on policies to make sure that that's MFA that is coming through your intuitive user-rich experience, and at the same time, benefit from Okta's extensible multi-factor suite that we have available, whether that's a push notification, SMS, email is a factor as was announced this year, duo, Yubikey, the list goes on. You didn't have to do anything on the Palo Alto device to support that, you were able to leverage the work that Okta's doing there. Ultimately, it leads to a successful authentication, a successful connection that was native right in the client VPN. With authentication magic, my authentication magic wand, we have as was demonstrated onstage, I'm not going to go through a demo because actually made a couple ... It was on the Keynote, the Citrix integration. That was one that Hassan and Erik Crolinsky went through yesterday demonstrating the capabilities of signing into Okta and getting right into a Windows desk top and what's happening there is that SAML Assertion's being process by a Citrix Netscaler in exchange for X509 certificate on behalf of the user and then it's being presented through to the desktop. So the user gets straight from Okta to a Windows desktop without being hunted for credentials that they either just got done typing at Okta, or potentially don't know depending on what the use case is.

The synopsis of it here is that Okta plus partners equals reduced friction, increased value, and ultimately solutions. If you take a look at the slides that we've just gone through, the capabilities, the things that we can do in there based on the products that you have are endless use cases that come to mind. These were old problems that I used to face, but something like that Citrix Netscaler integration could be something. I've got a customer CRN database that I'm using that ultimately feeds into Okta as the identity storer and I want to allow my customers to go through and do a software demonstration, but to do that it's an old one because we were packaging ... Old legacy software has to be installed, now I can extend to them the ability to get right into a desktop. Okta's AD agent can deal with the user provisioning, the user doesn't even know what that active director password is, and the solutions that you can build with the combination are really limitless, limited only by your own imagination. 

To demonstrate that, up next we've got our customer use case from Suresh Kurra. They were facing a very real problem and a real challenge and he's here to talk about how they solved that problem with a combination of Okta and a partner. So I'll turn it over to Suresh.

Suresh:  Thank you, Matt.

Matt Egan:  Thanks. 

Suresh:  So before I dive into the slides, I just want to give a brief overview of what Pitney Bowes is and what we are doing all around from the SaaS Services standpoint our legacy obligations. You can call legacy obligation, but it's the primary application of Pitney Bowes, which is at pb dot com. We have four different types of capabilities, self-serve capability and commerce capabilities, and also the support along with AM like marketing content. That's the complete separate ... I'm not going to say anything about AM at this moment, it'll be Adobe experience manager so let's dive in. Before I dive into the F file integration effort, I just want to highlight what we did before Okta and what we are achieving after we migrated to Okta. 

The story starts two years back where we have our incubation partners, IBM Cloud Identity, and we migrated to Okta started two years back but started eight months back, we migrated to all the four SAML apps communicating directly with Okta and our legacy app recently migrated back in April, which uses FI APM solution. As I mentioned, IBM used to be Cloud Identity management provider, there were a lot of reliable issues with them. That's one primary reason why we chose Okta. As you can see from the screen, Okta is really good and does ... There are a couple of outages, but it's resolved in a matter of minutes. In the past, we used to take two weeks with 15K Span on each SAML integration, whether it be federated or non-federated and now it can be done in less than a couple of hours. Not from the production standpoint, but at least from the testing standpoint, we can definitely do it in a couple of hours with no additional cost.

We used to have only 5 SAML applications in the past, and now we have close to 35 plus applications. There was no OAuth integration in the past, and we got Oauth integration to 75 percent of our applications. In the past, we used to ... We don't have much access to the logs or data reports, or if you want to do any customized reports, the capability's very limited, but now with Okta, we can do everything at our finger tips. Multiple Outages happen in the course of the five years we were with IBM Cloud Identity, and every outage usually takes about two hours to resolve by the time you get them on call and try to resolve it. With Okta, it's a matter of minutes. There used to be a lot of integration points in the past, and now with F5 APM, it's only one integration point

As you can see here, this is the prior architecture where we have dually accessed web seal acting as a reverse proxy where replaced that with F5 APM. As you can see, we have SAML applications and they communicated directly to Okta. We rolled out that 30 plus applications in the last two years which communicated directly with Okta. We did this thing in a two phase approach, the reason being that we want to reduce friction with the customers as much as possible because when you force a user to try to change his password, it's not good. We wanted to capture as many passwords as possible prior to migrating to the new solution. As you can see here, in the past, we used to maintain everything SSO, SAML integrations, entitlements, everything is managed by IBM. With Okta, we replaced everything with APM which basically translates the SAML Assertions back into HTTP based headers. Our legacy application is completely HTTP header based and that is what I'm going to talk abour from the bottom column.

As you can see, F5 pretty much provides SSO integrations, policy-driven access controls, you can have session affinity there is a key. When you guys define sessions, that's the primary crux of the problem. The entire challenge for Aziz? Session management. Because our application has two different qualities. One is guest flows because we had a commerce application where people can come in, add things to their cart. Up until that point, it's a guest flow. And once they sign in, it's an authenticated flow. That is where most of our session management issues came into picture during the implementation of F5. 

As you can see here, I don't know how many of you guys are currently F5 customers, could you guys raise your hands? Yeah, there's significance. So you guys know being F5 as our partner, we just started. We looked at multiple options in the past, which implementation partner we need to look for, but eventually we found APM is the right solution for our application suite so we decided to vote APM and pretty much it's a four step process. People might see this as too much of a complex thing, but in reality, it is not. Everything is based off of iRules which I am going to talk about in the end of the conversation. Basically you create ... Let's go through those steps. You create an application in the Okta Admin console. Basically you provide all of the necessary configurations, whatever is needed, and pretty much most of you guys who are Okta customers go through this screen.

This is an F5 Admin console where you can see the second step is to create the SAML SP for Okta. You go into this screen and you basically set up your configurations and go through that access policy as SAML and set BIG-IP as your SP. If you want to sign the assertions, you can do that, or if you want to sign the authentication, you have multiple options, as you can see here. The next one is, once you are done with those two steps, then you need to bind your IDP connector to the SP service. In order to the do that, F5 has provision in the Admin console where you can bind and unbind you idP connectors using these screens. By the way, we are running on 11.4 We are planning on migrating to 12RX. I believe they recently released ...

You define all your session management parameters in everything in the binder and you can go through those screens and fill in all the necessary components and details and when you're done with this, you'll simply go through this and bind that SAML lot as you can see from the screen. Most of them are screenshots. All this information is available on the f5 Okta integration document, which Okta team put together. 

Then you create an access policy and you bind this to the access policy, that' the next step over here. So how you are going to do that Access policy? All of the screens that we went past, and now you set this access profile to be a virtual server on the F5 APM. Here is two screens where you basically add that policy to the virtual, and then, this is the important topic that I'm going to talk about. At that point, your set-up is almost done, but the things that you need to care about is data group lists, because we have guest as well as non guest flows, like authenticated flows. We divided two groups as part of the data group lists on APM. One, where we can bypass APM and, by default, everything is protected by APM. Another set of group where we have certain there are group list. It can be contents or it can be sub folders, it can be set up whatever you want. Sorry, I need to go back.

Here are the major issues for us. Session management, as I mentioned earlier, where we have multi-browser issue. You open the tabs in the second tab, third tab, f5 is throwing that error. You will see the session is timed out or the session is logged out. In order to avoid that we implemented an iRule, custom iRule. I'm going to show you how that iRule is going to look like, and likewise, the header manipulation. When the SAML Assertion comes back, you need to translate that into HTTP headers. You extract those values from SAML Assertion, and pass it on to the application. Likewise, vulnerability mitigation. There are some existing issues with the current version of APM that we are using. To overcome those, we implement some od the custom iRules. Last but not least, Resource Location. There are realistic parameters within APM where you can tell when to sign or log out across different applications, and also where to redirect after the log out happens, or where to redirect after the log in happens. All of those details are a part of iRules.

These are the actual iRules we implemented. The screenshot is pretty small, but I can explain just by looking at that. 

Sessioneval-combined is nothing but as I mentioned the two-tab thing, like, when you open the second tab, the session is getting lost. In order to overcome that issue, we implemented that iRule. The next one is the SAML post stale session. Sometimes the session gets lost in the middle because of the APM bug. For that, we implemented F5 iRule. Basically depending on that MRX session, I don't know how many of you guys are familiar with MRX Session, that is the crux of the problem. MRX Session is the one which we use to manage our cookies and to manage our session. The third one is the secure iRule. That is where we know which there are group lists we have to go through, whether it is a bypass list or whether it is part of authenticated list and we go through that. This Relaystate Logout which I explained earlier. That pretty much navigates the user to where the origin or wherever the user wants to go when they log in, obviously the redirection has to happen, and when they sign out, they have to go back to the log in page. That's SOL 17387 is provided by APM itself, and we want to be able people accessing the root of the directory. So that's why we included one more iRule for Root Redirect. Obviously, we have several 302 Redirects.

Here is the sample code, which shows multiple attributes passed through Okta and how the SAML Assertions get translated by APM into HTTP headers. I just quickly put first name, last name, email address. You can pass on any information you guys want to pass to your application. 

These are the two additional resources you have and pretty much, it's self explanatory and pretty good documentation. So go through that.

I think we are done. Feel free to ask any questions.

Matt Egan:  Yeah. Yeah, so I think the important thing, here, there's some additional sessions that are probably relevant, but we also wanted to open up at the end for questions as I said in the beginning and I'd love to hear the use cases that people have. In my role in business development, I have opportunities to go out and engage different partners and different ISV's to overcome challenges so if there's questions that come up from the content or a question that's specific to your problem, we do have more time than I anticipated, so if we want to get into the meat of that, now's a good time. If we could open it up for questions. Jake, I know you have one. Yeah.

Audience member:  Did you already own the F5 infrastructure? And if that's the case, or otherwise, what's an issue to have all the F5.

Suresh:  Yeah, we have F5 LTM and GTM competence already in place in our infrastructure and that's one primary reason we didn't want to bring in another vendor. This satisfies our solution. APM was added as an add-on component. 

Audience member:  Okay, and how big is that now? I mean, infrastructure? Was the cost an issue for you?

Suresh:  It depends upon your use case. Our use case is ... We have roughly right now about 1.7 million users, so it depends upon your application use case.

Audience member:  Okay, thank you.

Matt Egan:  An important thing to note in there, in PB's case, they were able to displace some content, or some infrastructure and it netted out to the point where they were neutral or positive. As you guys are looking at your infrastructure footprint, generally these integrations are intended to ultimately maximize the value, extract more value out of integrations in the product that you already have. Yeah?

Audience Member:  Have you tried inserting a multi-factor into that authentication flow?

Suresh:  No, not really. F5 has that and Okta has it, we haven't tried that yet.

Audience Member:  Is there any thoughts if it would or would not work, or any insight there?

Suresh:  As we didn't implement, I really don't know. 

Matt Egan:  It would still work, you just put it in front of that SAML flow and so, were there a need, you would benefit from that, and if it needed to be specific resources, it might just be a matter of implementing the appropriate rules to align with those things.

Alright, good. If there's no other questions ...

Suresh:  Thank you all.

Matt Egan:  We'll yield the time, give you guys a jump start on lunch. Hope you guys have benefited from it. Again, check out, there are some additional sessions that are aligned to catch, and we look forward to seeing you around. Thanks.