From d42ca9ded99ea27fdb983dc03f4cedc8e6a82cc7 Mon Sep 17 00:00:00 2001 From: ned-oleary Date: Tue, 28 May 2024 15:12:40 -0700 Subject: [PATCH] migrating tutorial mdx from mintlify --- fern/docs.yml | 12 ++ fern/pages/idp-config-tutorials/entra.mdx | 124 ++++++++++++++ fern/pages/idp-config-tutorials/google.mdx | 108 ++++++++++++ fern/pages/idp-config-tutorials/jumpcloud.mdx | 145 +++++++++++++++++ fern/pages/idp-config-tutorials/okta.mdx | 127 +++++++++++++++ fern/pages/idp-config-tutorials/ping.mdx | 154 ++++++++++++++++++ 6 files changed, 670 insertions(+) create mode 100644 fern/pages/idp-config-tutorials/entra.mdx create mode 100644 fern/pages/idp-config-tutorials/google.mdx create mode 100644 fern/pages/idp-config-tutorials/jumpcloud.mdx create mode 100644 fern/pages/idp-config-tutorials/okta.mdx create mode 100644 fern/pages/idp-config-tutorials/ping.mdx diff --git a/fern/docs.yml b/fern/docs.yml index 2b547c6..1841379 100644 --- a/fern/docs.yml +++ b/fern/docs.yml @@ -13,6 +13,18 @@ navigation: snippets: python: ssoready typescript: ssoready + - section: IDP configuration + contents: + - page: Entra (formerly Azure AD) + path: ./pages/idp-config-tutorials/entra.mdx + - page: Okta + path: ./pages/idp-config-tutorials/okta.mdx + - page: Google + path: ./pages/idp-config-tutorials/google.mdx + - page: JumpCloud + path: ./pages/idp-config-tutorials/jumpcloud.mdx + - page: PingOne + path: ./pages/idp-config-tutorials/ping.mdx navbar-links: - type: primary diff --git a/fern/pages/idp-config-tutorials/entra.mdx b/fern/pages/idp-config-tutorials/entra.mdx new file mode 100644 index 0000000..57b6be8 --- /dev/null +++ b/fern/pages/idp-config-tutorials/entra.mdx @@ -0,0 +1,124 @@ +--- +title: 'SSO with Entra' +description: 'How to set up SSOReady connections with Entra (formerly Azure Active Directory)' +--- + +{/* ==================================================== */} +{/* Entra */} +{/* ==================================================== */} + + + +Entra -- formerly Azure Active Directory -- ranks among the more common IDPs. Like many Microsoft products, it can appear complicated. Hopefully it feels a little bit easier with this guide. + + +### Create an application in Entra + +Entra needs to associate a SAML connection with an *Application*, so our first step will require us to create an application. From any page in Entra, we can find *Applications* > *Enterprise applications* in the left navigation bar. We'll want to click here to navigate to the next page. + + + + + +We'll reach a page that says **Enterprise applications** in bold typeface. We simply need to press the *New application* button right under this header. + + + + + +On the next page, we'll see a header: **Browse Microsoft Entra Gallery.** We'll also see a few prominent cards with major cloud providers. Ignore all this; we won't use the gallery. Simply click *Create your own application*, which triggers a slideover from the right. + + + + + +Entra requires a display name for the application. The name we choose doesn't matter much. In most cases, you'll want your product's name to go here. +As we type a display name for the application, Entra will try to find matching apps from the Entra Gallery and suggest them as alternatives. In most cases, we should ignore this. + + + + +Under the display name, Entra offers three radio button options. We want to select the last one, which reads *Integrate any other application you don't find in the gallery (Non-gallery)*. + + + + + +Then we hit *Create* in the lower left of the slideover, and we're free to configure our Application. + + + + + +Entra may require a few seconds to create the Application. Once it has finished, you will land on a page detailing the application we've just created. + + + + + + +For now, we'll skip assigning users to your Application, but an Entra admin will need to assign them before long. + +Users cannot sign in until assigned to your Application by an Entra admin. + + + +### Configure SAML Connection | Enter SSOReady details in Entra + +Now that we have a SAML Connection created in SSOReady and an Application in Entra, we can configure each of them to communicate with the other. We'll start by entering details about our SSOReady SAML Connection into our Entra Application. Select the *Set up single sign on* card. + + + + + +Entra will then present a few options. We need to select the *SAML* card marked with a puzzle piece icon. + + + + + +Entra will route us to its *SAML-based Sign-on* configuration page, where we'll direct our attention first to the *Basic SAML Configuration* card. It has two required values. SSOReady supplies both. + +Click the *Edit* button in the top right corner of the *Basic SAML Configuration* card; we'll see a slideover triggered on the right. + + + + + +In the slideover, Entra requires us to enter two values: an *Identifier (Entity ID)* and a *Reply URL (Assertion Consumer Service URL)*. + +1. Let's start with the *Identifier (Entity ID)* field. In SSOReady, we call this the *SP Entity ID*, which you can find by navigating to your SAML Connection in the SSOReady app. Paste the URL from SSOReady into Entra. + +2. Next we'll do the *Reply URL (Assertion Consumer Service URL)* field. In SSOReady, we call this the *Assertion Consumer Service (ACS) URL*. It should look just like the *SP Entity ID* field, only it ends with `/acs`. Paste the URL from SSOReady into Entra. + + + + +Make sure to hit *Save* toward the top of the page. + + + + + +Once we've completed this step, Entra knows everything it needs about the SSOReady Connection. Next, we need to supply the SSOReady app with information about Entra. + + +### Configure SAML Connection | Enter Entra details in SSOReady + +Having set up Entra with information about SSOReady, we then supply SSOReady with information about the Entra Application. SSOReady needs three pieces of information from the Entra Application: an *IDP Entity ID*, a *Redirect URL*, and a *Certificate*. + +For convenience, we'll actually start with the last of these, the *Certificate*. In Entra, you'll find this on the third card, closer to the bottom of the page. Next to the *Certificate (Base64)* heading, Entra shows a blue download link. Click this link. It will download a file named for your application. For example, if we've named the application `new_application`, Entra will share a `new_application.cer` file. Upload this file to SSOReady on the page detailing the SAML Connection. + + + + + +For the final two pieces of information, we'll need to scroll down to the fourth card. Copy the *Microsoft Entra Identifier* field from Entra and paste it into SSOReady's *IDP Entity ID* field. Then copy the *Login URL* field from Entra and paste it into SSOReady's *Redirect URL* field. + + + + + + + +Once you've entered that data in SSOReady, you're finished with Entra configuration! \ No newline at end of file diff --git a/fern/pages/idp-config-tutorials/google.mdx b/fern/pages/idp-config-tutorials/google.mdx new file mode 100644 index 0000000..3ac0a09 --- /dev/null +++ b/fern/pages/idp-config-tutorials/google.mdx @@ -0,0 +1,108 @@ +--- +title: 'SSO with Google Identity' +description: 'How to set up SSOReady connections with Google Identity' +--- + +{/* ==================================================== */} +{/* Google */} +{/* ==================================================== */} + +Some companies will use Google Identity for SAML single sign-on. Please note that SAML single sign-on via Google Identity differs from "Sign in with Google," which uses the [OAuth protocol](https://datatracker.ietf.org/doc/html/rfc6749). If you want to offer your customers "Sign in with Google" functionality, you may wish to consult [Google's documentation](https://datatracker.ietf.org/doc/html/rfc6749) or use another authentication vendor. + +Before proceeding, please confirm that you indeed need SAML single sign-on via Google. + +As a first step, we will need a Google Workspace administrator to create an *App*. + + +### Creating a custom SAML app in Google Identity + +Starting from the Google Workspace admin page, i.e. [admin.google.com](admin.google.com), we'll need to navigate to *Apps* > *Web and mobile apps* in the left navigation bar. This link will send us to a new page. + + + + + +We'll land on a page with the header *Apps* > *Web and mobile apps*. Right under the header, we'll see a few tabs. We want to click *Add app* > *Add custom SAML app*. This link will send us to another new page. + + + + + +We'll land on a page with a large blue header reading *Add custom SAML app*. This page requires us to assign the application an *App name*. The *App name* matters solely for display purposes, so you'll typically want the *App name* to match your product's name. + +After typing the *App name*, we'll hit the blue *CONTINUE* button in the lower right. + + + + + + +### Configure SAML Connection | Enter Google details in SSOReady +Clicking *CONTINUE* in the previous step will direct us to a new page, again with the same blue header. + +The previous page enumerated a few steps directly below its header. It's totally normal for those to have disappeared. We're likely still on the right track. Scroll up on this page to display the steps again. + +Here, we'll find a few important details about the new Google Identity app that SSOReady needs to know about. We'll copy each of these from Google into SSOReady. + +First, let's scroll down to the field marked *SSO URL*. SSOReady calls this the *Redirect URL* on the *Identity Provider Configuration* card for your SAML Connection. Copy this URL from Google and paste it into the SSOReady web application. + + + + + +From here, we'll direct our attention to Google's *Entity ID* field. It sits directly under the *SSO URL* from the previous step. + +Copy this *Entity ID* URL and paste it into SSOReady as the *IDP Entity ID*. You'll find the input field for the *IDP Entity ID* adjacent to the *Redirect URL* input field from the previous step. + + + + + +We need just one more detail from Google. + +Navigate to the next field marked *Certificate*. Then, toward the top right corner of this *Certificate* field, we'll see a download icon. We want to press the download icon; doing so downloads a `.pem` file. Its name will match the header you see here, something starting with `Google` and ending in `SAML2_0`. + +We need to upload this `.pem` file to SSOReady as the *Certificate* in SSOReady's web application. + + + + + +Once we're done with this step, SSOReady has all the information it needs. Now we simply need to supply Google with the relevant information about SSOReady. + +A blue *CONTINUE* button sits toward the bottom right of the page. It may not be visible until you scroll down. Press this *CONTINUE* button. + + +### Configure SAML Connection | Enter SSOReady details in Google + +Once SSOReady knows about the Google app we've created, we need to tell Google about SSOReady. Google needs two pieces of information. + +First, Google asks for an *ACS URL*. In SSOReady, we call this an *Assertion Consumer Service (ACS) URL*. You'll find it on the *Service Provider Configuration* card for your SAML Connection. It ends in `/acs`. + +Copy this *Assertion Consumer Service (ACS) URL* and paste it into Google's *ACS URL* input field. + + + + + +We'll walk through a similar pattern for an additional set of fields. + +Directly below its *ACS URL* field, Google asks for an *Entity ID*. In SSOReady, we call this the *SP Entity ID*. You'll find this URL right next to the *Assertion Consumer Service (ACS) URL* in SSOReady's web application. As it turns out, the *SP Entity ID* looks exactly like the *Assertion Consumer Service (ACS) URL*, only it lacks the `/acs` ending. + +Copy the *SP Entity ID* from SSOReady and enter it as the *Entity ID* in Google. + + + + + +Click the blue *CONTINUE* button in the lower right corner. + + + + + +Once we've completed this step, we're done! You now have your product hooked up to your customer's Google Identity instance. + +Please note that your users can not successfully log in until your customer's Google Identity administrator assigns them to the application we created. This, however, requires no input from you. + + \ No newline at end of file diff --git a/fern/pages/idp-config-tutorials/jumpcloud.mdx b/fern/pages/idp-config-tutorials/jumpcloud.mdx new file mode 100644 index 0000000..98eddd6 --- /dev/null +++ b/fern/pages/idp-config-tutorials/jumpcloud.mdx @@ -0,0 +1,145 @@ +--- +title: 'SSO with JumpCloud' +description: 'How to set up SSOReady connections with JumpCloud' +--- + +{/* ==================================================== */} +{/* JumpCloud */} +{/* ==================================================== */} + + + +### Creating a JumpCloud application +We'll start our JumpCloud set-up by creating an *Application*. From JumpCloud's admin console, we want to click *SSO Applications* in the left navigation pane. This will take us to a new page -- the precise page we see depends on how many existing connections the JumpCloud instance has. + + + + + +{/* + + + +*/} + +After clicking *SSO Applications*, we'll see a *Configured Applications* page listing any configured SSO apps. On this page, we'll click the green *Add New Application* button toward the top left; it will route us to another new page. + + +If your customer has no pre-existing SSO applications in JumpCloud, you'll see a page with a *Get Started* button instead. In this case, we'll just click *Get Started*. + + + + + + +By this point, we will have arrived at a page reading *Create New Application Integration* in the top left with several cards featuring the logos of common SaaS applications. We'll direct attention to the *Custom Application* card in the lower right and click where it says *Select*. This will send us to a new page. + + + + + +Upon arriving on this next page, we'll simply click *Next* in the lower right to move on and see the next page. + + + + + +Here, we'll see a few checkboxes. We'll want to check the first of these, labeled *Manage Single Sign-On (SSO)*. Checking this box will trigger two radio buttons to expand. We'll select the first option: *Configure SSO with SAML*. + + + + + +Next, simply click *Next* in the lower right corner. + + + + + +JumpCloud wants us to assign a *Display Label*. We should fill this field with the name of your product. + + + + + +Having entered a *Display Label*, we'll simply click *Save Application* in the lower right corner. This will send us to a new page. + + + + + +On this page, we just need to press *Configure Application*. + + + + + +We've now completed the first step of JumpCloud configuration and can move to the next step, entering details about SSOReady into JumpCloud. + + +### Configure SAML Connection | Enter SSOReady details in JumpCloud + +JumpCloud needs two important pieces of information from SSOReady. + +We'll start with the first of these, a field JumpCloud calls the *SP Entity ID*. As it turns out, SSOReady assigns this data the same name. In the SSOReady web application, we'll navigate to the detail page for the relevant SAML connection. From this page, we'll simply copy the URL labeled *SP Entity ID* and paste it into JumpCloud's *SP Entity ID* field. + + + + + +After addressing the *SP Entity ID*, we'll progress to the next step. + +JumpCloud asks for *ACS URLs*. SSOReady provides exactly one for you. + +Navigating back to the SSOReady web application, we'll find a URL marked *Assertion Consumer Service (ACS) URL* associated with your SAML Connection. As it turns out, this your URL looks nearly identital to the *SP Entity ID* from the previous step. Moreover, it looks nearly identical to the *SP Entity ID*, only affixed with `/acs` at the end of the URL. + +We simply need to copy the *Assertion Consumer Service (ACS) URL* from SSOReady and paste it into JumpCloud as an *ACS URL*. + + + + + + +Once we've pasted in the *ACS URL*, JumpCloud has all the information it needs about SSOReady. + + +### Configure SAML Connection | Enter JumpCloud details in SSOReady + +Our next step requires us to copy a few details from JumpCloud into SSOReady. + +First, we'll scroll down to a URL that JumpCloud calls the *IDP URL*. In SSOReady, we call this the *Redirect URL*. Copy JumpCloud's *IDP URL* and paste it into SSOReady as the *Redirect URL*. + + + + + +SSOReady also needs an *IDP Entity ID*. It turns out that JumpCloud doesn't provide one, but it's fine for our purposes if we just enter two matching strings in both JumpCloud and SSOReady. + +We'll simply write "JumpCloud" in SSOReady. We then need JumpCloud to match, so we'll identically write "JumpCloud" in the field that JumpCloud calls *IDP Entity ID*. + + + + + +Next, we need to upload a *Certificate* in SSOReady. We'll find the file we need on the left side of the overlay we've been working in. We'll need to press *Download Certificate* > *Upload new Certificate*. JumpCloud creates a file called `certificate.pem`. We then upload this file to SSOReady as the *IDP Certificate*. + + + + + +We need to adjust one very important setting in JumpCloud before we finish up. Where JumpCloud writes *Sign* we need to change the radio button setting to *Assertion and Response*. JumpCloud's default setting will not work properly with SSOReady. + + + + + + +Then we need to hit *Save* in the bottom right corner. + + + + + +We've now finished connecting SSOReady to JumpCloud. Please note, however, that your customer's JumpCloud admin will need to assign users to your application before they can successfully sign in. + + \ No newline at end of file diff --git a/fern/pages/idp-config-tutorials/okta.mdx b/fern/pages/idp-config-tutorials/okta.mdx new file mode 100644 index 0000000..68c6bdc --- /dev/null +++ b/fern/pages/idp-config-tutorials/okta.mdx @@ -0,0 +1,127 @@ +--- +title: 'SSO with Okta' +description: 'How to set up SSOReady connections with Okta' +--- + +{/* ==================================================== */} +{/* Okta */} +{/* ==================================================== */} + +As a first step, we need to create an *Application* in Okta. The Okta *Application* will mediate all login interactions with SSOReady. Once we've finished setting it up, your users may see it as a tile in their Okta accounts. + +Once we've successfully created an *Application*, we'll swap details between SSOReady and Okta to enable single sign-on. + +### Create an application in Okta + +To create an *Application* in Okta, we'll need your customer's Okta administrator to select *Applications* > *Applications* in the left nav panel. + + + + + +We'll land on a page with a bold **Applications** header. Right under the header, we'll select the dark blue button that reads *Create App Integration*. + + + +Okta will flash a model offering you several radio button choices. Of these, we want to select *SAML 2.0* and then simply press *Next* in the lower right corner. + + + + + + +Once we've selected *SAML 2.0*, Okta will change the header to read *Create SAML Integration* as below. Okta requires a display name. We can write mostly anything here, but it's probably best simply to write your product's name. + + + + + +The remaining options on this page aren't especially important; we can simply select *Next* here, which finalizes our creation of an Okta *Application*. We can now move on and connect Okta to SSOReady. + + + + + + +### Configure SAML Connection | Enter SSOReady details in Okta + +Hitting *Next* on the prior page will have nudged us into a new tab, marked *Configure SAML*. Here, we'll start by copying two pieces of data from SSOReady into Okta. + +At the top of the page, Okta asks for a *Single sign-on URL*. You will find this URL in SSOReady on the detail page for your SAML Connection; we call it the *Assertion Consumer Service (ACS) URL*. It typically ends in `/acs`. Copy this *Assertion Consumer Service (ACS) URL* and paste it where Okta has written *Single sign-on URL*. + + + + + +From here, we'll proceed to the next field on the same page. It reads *Audience URI (SP Entity ID)*. In SSOReady, we call this the *SP Entity ID*. You'll find it directly under the *Assertion Consumer Service (ACS) URL* in the SSOReady app. It usually looks just like the ACS URL, except it does not end in `/acs`. + +Paste the *SP Entity ID* URL from SSOReady into Okta's *Audience URI (SP Entity ID)* field. + + + + + + +Once we've filled the *Audience URI (SP Entity ID)* field (and scrolled down to hit *Next* in the lower right corner), we've completed all the necessary data entry from SSOReady into Okta. + + +### Configure SAML Connection | Enter Okta details in SSOReady + +Having entered the necessary SSOReady data into Okta, we'll move on. + +Okta requires one brief detour wherein we supply feedback to their team. + +We'll want to select *I'm an Okta customer adding an internal app*, skip the remaining questions, scroll down, and press *Finish* in the lower right corner. + +{/* ==================================================== + + + + + +*/} + + + + + +Okay, **now** we can enter Okta data into SSOReady. The previous step will have routed us to a page with your application's name at the top. + +From here, we need to scroll down a bit and hit *More details*. It's not always easy to see. + + + + + +Once we've expanded the details for the SAML application, we'll see a bunch of data. + +Directly under the *More details* button, we'll see a URL marked *Sign on URL* with a light purple *Copy* button. In SSOReady, we call this the *Redirect URL*. Simply copy this URL and paste it into SSOReady as the *Redirect URL*. + +{/* ==================================================== + + + +*/} + + + + + + +Scrolling somewhat further down, we'll see a similar line for a URL that Okta labels *Issuer*. In SSOReady, we call this the *IDP Entity ID*. Copy this *Issuer* URL and paste it in SSOReady as the *IDP Entity ID* in SSOReady. + + + + +Finally, SSOReady requires that we upload a Certificate. We'll find this even further down on the same page. Okta labels this the *Signing Certificate.* Please be aware that Okta has several related buttons that will not give us what we need. We'll press the rectangular *Download* button, which will yield an `okta.cert` file. + +We'll then upload `okta.cert` to SSOReady as the Certificate for this SAML Connection. + + + + + + Once we've uploaded the Certificate, we're all set! We've finished the SAML configuration. It's important to remember, though, that your customer's Okta administrator will still have to assign users to your application before they can sign in. + + + \ No newline at end of file diff --git a/fern/pages/idp-config-tutorials/ping.mdx b/fern/pages/idp-config-tutorials/ping.mdx new file mode 100644 index 0000000..157bfdb --- /dev/null +++ b/fern/pages/idp-config-tutorials/ping.mdx @@ -0,0 +1,154 @@ +--- +title: 'SSO with Ping Identity' +description: 'How to set up SSOReady connections with Ping Identity' +--- + +{/* ==================================================== */} +{/* Ping Identity */} +{/* ==================================================== */} + + +### Creating an application in Ping Identity + +We'll start our Ping Identity setup from your customer's administrator home page. Exactly how this looks will vary. Our example uses a newly provisioned account and therefore shows an onboarding guide; your customers' admin pages will look different in most cases. + +Nonetheless, we'll always start by hitting *Applications* > *Applications* in the left navigation bar. This will take us to a new page. + + + + + +Once we've navigated to Ping's *Applications* page, we'll want to press the circular blue button with a plus icon toward the top left. This will trigger a slideover. + + + + + +Ping wants us to assign the Application an *Application Name*. Our choice of name has no impact on Ping's integration with SSOReady, but Ping will use the *Application Name* as your product's display name. We'll likely want the *Application Name* to match your product's name exactly. + + + + + +Then we need to tell Ping that our Application uses SAML. Click the card that reads *SAML Application*. You may notice that this changes the text on the blue button below from *Save* to *Configure*. + + + + + +Here, simply select *Configure*. This finalizes creation of our SAML application and progresses us to the next step. + + + + + +Next, we'll have to enter some details about SSOReady into Ping. + + + +### Configuring a SAML Connection | Entering SSOReady data in Ping Identity + +We'll now wee a page with a *SAML Configuration* header. It will present three radio button options; of these, we'll select *Manually Enter*. Doing so will trigger two input forms below the radio buttons. + + + + + + + +Ping Identity requires two pieces of information about the SAML Connection we'll establish with SSOReady. Let's start with the first one. + +Ping first asks for *ACS URLs*. SSOReady provides exactly one of these. You'll find it on the detail page for your SAML Connection in the SSOReady web application. We've labeled it *Assertion Consumer Service (ACS) URL*. It always ends in `/acs`. + +Copy the URL from SSOReady and paste it into Ping here. + + + + + +We'll do something similar again for a field Ping calls *Entity ID*. In SSOReady, we call this an *SP Entity ID*. We can find it adjacent to the *Assertion Consumer Service (ACS) URL* in the SSOReady web application. One might notice it matches the *Assertion Consumer Service (URL)* exactly, except it lacks the `/acs` suffix. + + + + + +We'll then simply hit *Save* toward the bottom of the page, concluding our entry of information about SSOReady into Ping. + + + + + + + +### Configuring a SAML Connection | Entering Ping Identity data into SSOReady + +Just as we entered information about SSOReady into Ping, so too will we need to enter information about Ping into SSOReady. + +To start, let's make sure we find ourselves on the *Configure* tab. In a moment, we'll pull three pieces of information from this tab. + + + + + +SSOReady requires a *Certificate* from Ping. You'll find the appropriate uploader on the SAML Connection detail page in your SSOReady web application. + +We'll find this by clicking the *Download Signing Certificate* button and selecting *X509 PEM (.crt)* from the menu. + +We'll see a `.crt` file begin to download. If the file has a long and non-descriptive name, that is normal. + +We'll then upload the file to SSOReady as-is, which allows us to move to the next step. + + + + + +After we've taken care of the Certificate, we'll need a field that SSOReady calls an *IDP Entity ID*. It's an input field on the same card as the Certificate uploader. + +Ping calls this information an *Issuer ID* and places it directly under the *Download Signing Certificate* from our previous step. + +We'll simply copy this URL from Ping and paste it into SSOReady as the *IDP Entity ID*. + + + + + +Finally, we'll find a field that Ping calls the *Single Signon Service*. In SSOReady, we call this a *Redirect URL*. Just as we did before, we'll copy the *Single Sign On Service* URL and paste it into SSOReady as the *Redirect URL*. + + + + + +Once we've copied over the *Single Signon Service* URL, we're done swapping information between SSOReady and Ping Identity, which means we're almost finished with set-up altogether. + +We'll now navigate to the *Attribute Mappings* tab to adjust one final setting in Ping. + + + + + + +### Configuring a SAML Connection | Adjusting Ping attribute mappings + +Here, we'll see three headers: *Attributes*, *PingOne Mappings*, and *Required*. Where we see *saml_subject* under *Attributes*, change the corresponding *PingOne Mappings* field. This will trigger a dropdown selector. We want this field set to *Email Address*. + + + + + +Finally, we'll hit *Save* and the bottom. + + + + + +In the top right, we'll change the toggle from *off* to *on*. + +We're all done! + + + + + +Please do bear in mind, however, that your customer's Ping admin will still need to assign users to this application before they can sign in. This requires no action from you as a service provider. + + \ No newline at end of file