3 ms·
Note: I'm not connected with the GP in any way and do not have any financial or material interest in Okta. Users don't necessarily have to be employees, althou
by newscracker 9y ago
Note: I'm not connected with the GP in any way and do not have any financial or material interest in Okta.
Users don't necessarily have to be employees, although for many smaller companies the employees may be all the users. For example, say your company buys computers for your employees from a vendor and gives the vendor access to one of your applications to send invoices and manage orders (with appropriate controls and privileges). You would want to manage this external vendor user in a way similar to how you manage employees' access to applications. For a system like Okta, this external person is also a user, though not your employee.
For your use case described above, a system/platform like Okta may be a good fit — all your user identity management and application access management would be on Okta alone.
Keep in mind that individual applications may still have copies of user identity and profile records and their own (closed) mechanisms of storing user privilege information. Those cases would have to be managed separately anyway, even though it generally may not cause any harm as such to keep such "junk" around when the main user identification record has been purged from a central system like Okta (the same can be said of AD, LDAP, etc.).
- skissane 9y agoOr consider the case of a university: users can be staff, students, contractors, alumni, and various other random categories. For example, at the university I used to work for, any member of the general public could purchase a library borrowing card, and that meant they had to have a login to the university library systems (to see what books they had borrowed).