<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
0D54z00009B8SpHCAVOkta Classic EngineLifecycle ManagementAnswered2024-08-30T09:01:19.000Z2023-05-16T21:22:05.000Z2023-05-18T16:16:47.000Z

c2ziv (c2ziv) asked a question.

Limit application access to set users - Concurrency rules via OKTA

hi,

 

Is it possible to implement concurrency rules via OKTA?

 

If I don’t want more than 100 people to access an application at a single time and we use OKTA for the authentication, can we block user 101 from logging in until there’s space free? 


  • NiallM.34104 (Atlas Identity)

    Short version is no. Longer version is also no, but with an explanation of why Okta can't do this. Okta has no sight of the state of your logged in users. It registers that a user has logged in at a point in time, but then redirects the authenticated user to your application. That user can then remain logged in, can logout locally, kill the cookie in their browser, close their browser, shutdown their laptop. Any event that will impact their logged in state happens on the client and Okta has no visibility of that. So it doesn't know if there are 100 logged in or 1000. Or 1. It does have a record of login events to your app, but not whether they are still logged in.

     

    Your app is the only place where the current state is known via sessions.

     

    You could ghetto it up and interogate the Okta logs for the authentication event metrics for your app and then make decisions based on that, but that's not the answer you want. It's also more effort than just have a record of valid sessions in your app and controlling access there.

    Expand Post
    Selected as Best
  • NiallM.34104 (Atlas Identity)

    Short version is no. Longer version is also no, but with an explanation of why Okta can't do this. Okta has no sight of the state of your logged in users. It registers that a user has logged in at a point in time, but then redirects the authenticated user to your application. That user can then remain logged in, can logout locally, kill the cookie in their browser, close their browser, shutdown their laptop. Any event that will impact their logged in state happens on the client and Okta has no visibility of that. So it doesn't know if there are 100 logged in or 1000. Or 1. It does have a record of login events to your app, but not whether they are still logged in.

     

    Your app is the only place where the current state is known via sessions.

     

    You could ghetto it up and interogate the Okta logs for the authentication event metrics for your app and then make decisions based on that, but that's not the answer you want. It's also more effort than just have a record of valid sessions in your app and controlling access there.

    Expand Post
    Selected as Best
  • c2ziv (c2ziv)

    Thanks for the confirmation, Niall.

     

    That's the same thing I was thinking of. It is the application that can determine how many active connections are there and it is the application where configuration can be made to allow no. of concurrent connections. I was just double-checking.

  • NiallM.34104 (Atlas Identity)

    It's an interesting question though. Okta's job is a point in time response to an authentication request. It sets a session in the cookie, but that is just for the client that performed the authentication. It doesn't ( certainly from an administrator perspective ) maintain the state of the logged in user even for Okta. It relies on the cookie on the client to maintain the logged in state. It doesn't maintain an internal database of the loggedinness ( made up word ) of all the users in the tenant. So extending that out to the apps that are onboarded for SSO is certainly not on the cards.

    Expand Post
This question is closed.
Loading
Limit application access to set users - Concurrency rules via OKTA