Demo: Single Sign-On & Session Management (Session Control, IDP & SP initiated SSO)

Speaker 1: Okta offers several features to control sessions. First, we'll show how to kill a user's Okta session and prevent log-ins. On the left, I'm logged in as an admin and on the right I'll log in as Joe. The admin suspects Joe is up to no good, so she finds his name and then she clears his session.

Speaker 1: She does so by clicking more actions and then clearing user session. This log's Joe out of Okta and you can see that by refreshing his browser, but he can still re-log in. The admin wants to prevent this while she investigates, so she suspends Joe indefinitely by clicking this button. This action is not destructive, meaning it won't deprovision Joe's downstream accounts. Both these capabilities are also available via API's for platform use cases., Just go to [email protected].

Speaker 1: Next, let's see how logging out of an application can trigger complete session termination at the IDP. We'll show SAML single log out with GoToMeeting, which we've previously set up in Element3.2. From Peggy's dashboard, I authenticate into GoToMeeting with SAML. We're now logged in and I have open sessions at Okta and GoToMeeting. Let's log out of GoToMeeting. Back at Okta, I refresh the browser and confirmed that logging out of GoToMeeting also killed my Okta session. This capability is available for any app that supports SAML single log out. We don't draw a distinction between on prem or federated SAS apps. Instead, Okta gives customers choice and flexibility on how they want to handle sessions. This is particularly useful for kiosk centers where many people use the same computer.

Speaker 1: Finally, let's see how we can configure different session timeouts for different groups of users. I logged back into Okta's admin council and let's view the default sign in policy. You can see the default Okta session is two hours by clicking on default rule and expanding it. Let's now configure a more stringent policy for kiosk users. We'll do so by adding a new sign on policy. We'll call it Kiosk Users and we'll make the supply to everyone who's in the Kiosk Users group. Next we'll add a rule. We'll give it a name of Kiosk Users and we'll set the session lifetime to 15 minutes, much shorter than the Okta default of two hours and that's it.

Speaker 1: We will now show Okta performing IDP initiated SAML to an HR application called Workday. My iPhone is on the left and browser on the right. Single sign on via browser straight forward. I just click on the chiclet. Notice how I'm prompted for a multi-factor on my phone when I try to access a sensitive HR application from an unknown IP address. I actually connected through an anonymizing VPN, which triggered the policy that I can figure out earlier. I simply click on this green button on my phone to approve the multifactor. This sends a message to the Okta service out in the cloud and then once Okta receives it, it will then perform SAML single sign on into Workday. And there you have it. Single sign on into Workday via SAML with the layer of multi-factor on top.

Speaker 1: I will now demo SP initiated SAML to Workday in three different scenarios. First, I will show what happens when there is no Okta session. Then I will show what happens when there is one. Finally, I'll show Okta's mobile experience with the native Workday Mobile App. I disabled MFA so we won't get prompted three times. Okay.

Speaker 1: Scenario one, let's go to Workday. There are no sessions anywhere. Workday redirects me back to Okta, which then asked me to authenticate. After I authenticate Okta sends a SAML assertion to Workday. We're now logged into Workday. Let's log out and do scenario two.

Speaker 1: So again, in scenario two, there is an Okta session, but no Workday session. Let's go to Workday. This time when we redirect back to Okta, notice that we do not get prompted to authenticate because we already have a session. Okta sends a SAML assertion to Workday and we're logged in. Let's now switch to my iPhone and see that experience. In my iPhone, I'll open Okta Mobile, which is an app that replicates the dashboard you'd see in a browser. You get the same chiclets and you can click on any of them to get us SSO, but most mobile users prefer native apps because of the superior usability. Note how Okta gives you that choice. Let's actually launch the native Workday app to see how it interacts. So again in my iPhone I click on Workday and I see a blue button to sign in with Okta Mobile. I'll click on that. This then checks with Okta Mobile to see if there's a valid session. Okta Mobile says there is and it begins a process of doing single sign on. There you have it. You now have the session with Workday in the native mobile app.

Speaker 2: A common problem that many users run into when accessing a deep link to a non-federated application is that the app prompts for authentication. To get around this problem, Okta provides a mobile Safari plugin that allows for a single sign on to the non-federated application. The user simply taps into the Okta mobile icon within mobile Safari and Okta will inject credentials for the end user.

Speaker 2: Alice enters a PIN and chooses an account and Okta will log her in to the non-federated application. Note that Okta is providing a single sign on solution regardless of how an app is authenticated. For example, federated versus non-federated applications or access, for example, web versus thick clients.