Okta for Directory, IdP, and SSO. ACM.149 Exploring Okta features that… | by Teri Radichel | Cloud Security

ACM.149 Exploring Okta features that might enable its use as an IdP for user authentication

Part of my series on Automating Cybersecurity Metrics. The Code.

In my last post I explained what an identity provider (IdP) is and differentiated this from single sign-on (SSO) in order to explain what I am trying to achieve in my upcoming posts.

Many variations exist for how and where user credentials can be stored and how users can be authenticated. An IdP usually stores user credentials and handles user authentication. The term for handing the authentication off to another system or service is called federation. That means the application itself does not validate the credentials itself, but passes that task off to another system. As we saw there are still many variations in how credential management may happen even in that scenario.

As I explained, if the system is simply storing the credentials and passing them on to some other third-party system to perform the authentication then that’s not really an IdP. That’s simply a mechanism to make it easier for users to login (SSO). That doesn’t really accomplish the architectural change I’m attempting to make by using a third-party authentication service.

As a reminder I want to break up the creation of users and providing access to those users so they occur with different credentials and sessions on different systems in hopes of thwarting this attack:

I have been pondering the idea of using OKTA as the primary directory for multiple cloud environments for a while now but have not gotten around to testing it. In this post, I’m going to look at some of Okta’s features, capabilities, and potential security gaps that I’ll explore in more detail in future posts. Some of the Okta documentation is scattered around so I might have missed something below in the authentication options. I’ll update this post if I find more while testing out the system.

Classic Engine vs. Identity Engine

Okta supports what it refers to as its Classic Engine and the newer Identity Engine. When reviewing the documentation you can see which version you’re looking at on the top right of the documentation:

Since the Identity Engine is the new and improved version, we’ll focus on that.

Okta as a primary User Directory

As mentioned in the last post, an IdP generally maintains the directory of users and their passwords which is used for authenticating login requests. Okta offers something they call “Universal Directory” which acts as a repository for all your users, groups, and devices.

Currently many organizations use Azure Active Directory or Active Directory as the source of truth for all the users in an organization. Okta (and many other companies) have tried to become an alternative to that option.

But can Okta’s Universal Directory really replace Active Directory or Azure Active Directory? Not if Microsoft can help it. Last time I tried I could not fully federate logging into Azure to Okta. We’ll take a closer look at the Universal Directory in upcoming posts. Perhaps things have changed since I last checked.

By the way, other companies want to do the same with services like Google Cloud Identity and JumpCloud. Other identity companies have tried and failed in the past with unreliable and not-so-secure services, though Microsoft Active Directory has had its own share of security challenges.

Can a company that focuses solely on authorization and identity management do better? Possibly. Though a company that solely focused on password management was just breached (LassPass) so a singular focus is not a guarantee of success.

Directory Integrations

If you want to use an alternate directory, Okta supports the following directory integrations. As I’ve already explained, I’m trying to test Okta as my source of truth directory so I won’t be usign the following. In this case we’re potentially copying and syncing things around which I don’t really want to do.

Active Directory

LDAP

CSV

Okta Dashboard for SSO

Okta really started as an single sign-on (SSO) solution. The goal was to make life easier for administrators and users who had to log into many different systems. I explained the difference between an IdP and SSO in my last post.

When you log into Okta you get a dashboard with a number of icons that you can click on to log into various systems.

As I covered in my last post, what happens when you click one of those buttons could vary depending on the implementation behind the scenes. The type of authentication process Okta can offer will depend on two things:

The mechanism(s) that Okta supports.
The mechanism(s) that the vendor you are logging into when you click the button supports.

What authentication options does Okta support for an external IdP?

You can allow users to authenticate with the following external IdPs when using Okta. That means Okta federates the authentication to the third-party IdP that stores the user credentials rather than storing and authenticating the user itself.

OIDC (Open ID Connect)

Open ID connect is a newer standard than SAML. It uses JSON web tokens instead of XML.

Generic OpenID Connect (OIDC) allows users to sign in to an Okta org using their credentials from their existing account at an OIDC Identity Provider (IdP).

SAML (Security Assertion Markup Language)

SAML was one of the primary protocol and standard used to federate the authentication process to an IdP for years. It is XML-based and some people consider OIDC to be simpler. That said, some older systems only support SAML.

Social IdP

Okta can work with external services like Facebook, Google, and Microsoft.

Smart Card IdP

Okta works with smart cards that contain an x.509 compliant digital certificate.

From the documentation:

A personal identity verification (PIV) card is a United States federal smart card that contains the necessary data for the cardholder to be granted access to federal facilities and information systems and assure appropriate levels of security for all applicable federal applications. PIV cards are very strong authenticators (up to IAL3/AAL3, per NIST guidance), which can replace the username and password as an authentication method where supported.

What types of protocols does Okta support for SSO?

RADIUS

Some firewalls and other systems require use of the RADIUS protocol which Okta supports as well.

Active Directory SSO

Use Active Directory credentials to log into apps.

OIDC integrations

OIDC tokens issued by Okta:

OIDC tokens issued by third-party application:

SAML

Similar to the above images, either Okta or the third-party can issue the SAML assertion.

WS-Fed

WS-Fed is used by some legacy Microsoft applications.

SWA (Secure Web Authentication)

Okta SSO uses this method for applications that do not support federation of the authentication process to Okta. This aligns with the scenario I wrote about yesterday where Okta acts as a “password manager in the sky.”

How Okta describes it:

Administrators can set the credentials for the application, or the end user can enter a specific username and password. Okta keeps the credentials for that application inside a secure store, encrypted with strong AES-256 encryption. After setting the credentials, end users only need to authenticate with Okta, and then they can SSO directly into the application.

This might be a good solution if you don’t want the user to have the credentials for an application, but then does the administrator see and have the credentials? That sets us up for potential credential abuse by insiders I wrote about in prior posts.

SCIM (System for Cross-Domain Identity Management)

SCIM is a method of automating the management of identities across platforms. We’ll take a look at SCIM in more detail in subsequent posts.

CASB

Okta offers some documentation for CASB integrations as well. We won’t be using a CASB for this particular assessment of the product.

What options does OKTA support for custom apps using the Okta API?

Okta describes two different authentication mechanisms in their developer documentation — redirect authentication and embedded authentication. This documentation does not specify to which engine it is applicable.

Redirect authentication

The user logs in at Okta and then is redirected to another application. In this case, the credentials are entered into an Okta hosted web pages and Okta considers this method more secure.

Okta says:

A user sign-in flow that grants authentication control to Okta by redirecting to an Okta hosted sign-in page using open protocols like OAuth 2.0 and SAML.

Redirect authentication through the Okta-hosted Sign-In Widget is considered the easiest and most secure means of integration. This is because the Sign-In Widget itself is hosted by Okta, maintained by Okta, and kept secure by Okta. The Okta-hosted Sign-In Widget is recommended for most integrations.

Embedded authentication

With the embedded option, your or the cloud service hosts a webpage that accepts the credentials, which are then used to authenticate at Okta. In this case, the credentials are exposed to the application hosting the sign-in page. This option is available in case the application using Okta to sign in requires more customization than is possible using the Okta sign-in widget.

Multi-factor authentication

Okta also offers MFA now. As the credentials are floating around between systems, if they are, enforcing MFA may help limit certain types of attacks. Of course, we’ll need to look ito the MFA implementation and test it out.

What happens when MFA is required on Okta and you want to enforce MFA on AWS using a condition in an AWS IAM policy? Luckily, Okta has a solution for that, but we’ll want to test it.

Considering our options

We’ll we are certainly not done at this point but we can see the different options Okta supports for the authentication portion of the solution. The question is, what do the platforms we want to log into support? Where will our passwords end up? What sort of security exists to protect the integration between the two systems? What sort of attacks might be possible for the solution we are trying to set up? And is true federation even possible? Can we delegate creation of users to one platform and access controls to the other?

Follow for updates.

If you liked this story ~ use the links below to show your support. Thanks!

Support:
Clap for this story or refer others to follow me.
Follow on Medium: Teri Radichel
Sign up for Email List: Teri Radichel
Follow on Twitter: @teriradichel
Follow on Mastodon: @[email protected]
Follow on Post: @teriradichel
Like on Facebook: 2nd Sight Lab
Buy a Book: Teri Radichel on Amazon
Buy me a coffee: Teri Radichel
Request services via LinkedIn: Teri Radichel or through IANS Research

About:
Slideshare: Presentations by Teri Radichel 
Speakerdeck: Presentations by Teri Radichel
Recognition: SANS Difference Makers Award, AWS Hero, IANS Faculty
Certifications: SANS
Education: BA Business, Master of Sofware Engineering, Master of Infosec
How I got into security: Woman in tech
Company (Penetration Tests, Assessments, Training): 2nd Sight Lab