From e89cb51138aa5b17918754c99718ab3bce7ac420 Mon Sep 17 00:00:00 2001 From: Susan Harper Date: Fri, 6 Sep 2024 17:01:48 -0600 Subject: [PATCH 1/8] first set of links --- .../docs/concepts/identity-providers/index.md | 2 +- .../docs/concepts/okta-data-model/index.md | 2 +- .../docs/concepts/policies/index.md | 22 ++++++------- .../build-custom-ui-mobile/main/index.md | 2 +- .../configure-signon-policy/main/index.md | 6 ++-- .../main/index.md | 2 +- .../main/index.md | 2 +- .../main/index.md | 32 +++++++++---------- .../docs/reference/api/policy/index.md | 16 ++++++++-- 9 files changed, 49 insertions(+), 37 deletions(-) diff --git a/packages/@okta/vuepress-site/docs/concepts/identity-providers/index.md b/packages/@okta/vuepress-site/docs/concepts/identity-providers/index.md index f8597d6643a..a8e056f3d05 100644 --- a/packages/@okta/vuepress-site/docs/concepts/identity-providers/index.md +++ b/packages/@okta/vuepress-site/docs/concepts/identity-providers/index.md @@ -117,7 +117,7 @@ You can also set up group sync to specify the groups that users should be added ## IdP Discovery -If you have more than one Identity Provider configured in your org (which can mean just one external Identity Provider, in addition to Okta itself also serving as an Identity Provider), you can define logic to determine which Identity Provider individual end users are routed to when they authenticate. This functionality is called IdP Discovery, or IdP Routing Rules, and is configured by the [IdP Discovery Policy](/docs/reference/api/policy/#idp-discovery-policy). +If you have more than one Identity Provider configured in your org (which can mean just one external Identity Provider, in addition to Okta itself also serving as an Identity Provider), you can define logic to determine which Identity Provider individual end users are routed to when they authenticate. This functionality is called IdP Discovery, or IdP Routing Rules, and is configured by the [IdP Discovery Policy](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy). The Okta Sign-In Widget (version 2.5.0 or above) interacts with the IdP Discovery policy to redirect end users as needed to the IdP determined by the policy. diff --git a/packages/@okta/vuepress-site/docs/concepts/okta-data-model/index.md b/packages/@okta/vuepress-site/docs/concepts/okta-data-model/index.md index 9108924b14c..1633e49bb56 100644 --- a/packages/@okta/vuepress-site/docs/concepts/okta-data-model/index.md +++ b/packages/@okta/vuepress-site/docs/concepts/okta-data-model/index.md @@ -26,7 +26,7 @@ An [Application](/docs/reference/api/apps/) holds information about the protocol The relationship between an app and a user is stored in Okta as an [AppUser](/docs/reference/api/apps/#assign-user-to-application-for-sso). This allows for mappings between profile values where they're different. For example, app1 may refer to a user's last name as `lastName` and app2 may refer to last name as `surname`. The AppUser stores the value as necessary for the app. -A [Policy](/docs/reference/api/policy/) specifies the rules of how your org behaves for certain actions. Policies have conditions that need to be met to apply actions. Your Okta org contains policies for how to gain access to an app, what the user needs to do to reset their password, and to enroll into multifactor authentication, for example. +A [Policy](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy) specifies the rules of how your org behaves for certain actions. Policies have conditions that need to be met to apply actions. Your Okta org contains policies for how to gain access to an app, what the user needs to do to reset their password, and to enroll into multifactor authentication, for example. An [authorization server](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/AuthorizationServer/) in your Okta org provides apps tokens that allow those apps to access either your API or Okta resources. This is done with protocols such as OAuth 2.0, OpenID Connect, and SAML. diff --git a/packages/@okta/vuepress-site/docs/concepts/policies/index.md b/packages/@okta/vuepress-site/docs/concepts/policies/index.md index 4c47071b3f2..1724b4acc80 100644 --- a/packages/@okta/vuepress-site/docs/concepts/policies/index.md +++ b/packages/@okta/vuepress-site/docs/concepts/policies/index.md @@ -30,7 +30,7 @@ There are many possibilities for policy use: The [global session policy](#global-session-policies) controls the manner in which a user is allowed to sign in to Okta by identifying the user and specifies the length of their session. -You can [configure a global session policy](/docs/guides/configure-signon-policy/main/) to require any of the [factors you set up](https://help.okta.com/okta_help.htm?type=oie&id=csh-configure-authenticators). Then use the primary and secondary factor conditions in a rule to define which factors are evaluated. For example, add a rule that prompts for additional factors so only users who are inside your [corporate network](/docs/reference/api/policy/#network-condition-object) have access. +You can [configure a global session policy](/docs/guides/configure-signon-policy/main/) to require any of the [factors you set up](https://help.okta.com/okta_help.htm?type=oie&id=csh-configure-authenticators). Then use the primary and secondary factor conditions in a rule to define which factors are evaluated. For example, add a rule that prompts for additional factors so only users who are inside your [corporate network](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicyRule!path=0/conditions/network&t=request) have access. ### Control how users access your app @@ -77,7 +77,7 @@ A default policy is automatically created for each type of policy. This ensures Default policies also always have one default rule that you can't delete, and that rule is always the last rule in the priority order. When you add rules to the default policy, they have a higher priority than the default rule. -The [`system` attribute](/docs/reference/api/policy/#policy-object) determines whether a system or an admin created the policy. Default policies and default rules are the only policies and rules that have this attribute. The `system` attribute set to `TRUE` on default policies or rules indicates that those policies and rules are system-created policies, and you can't delete them. +The [`system` attribute](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy!path=1/system&t=request) determines whether a system or an admin created the policy. Default policies and default rules are the only policies and rules that have this attribute. The `system` attribute set to `TRUE` on default policies or rules indicates that those policies and rules are system-created policies, and you can't delete them. ## Policy types @@ -89,11 +89,11 @@ Sign-on policies and rules enforce policies and rules so users sign in with the #### Global session policies -A [global session policy](/docs/reference/api/policy/#global-session-policy) controls who has access and how a user gains access to Okta. See [Global session policies](https://help.okta.com/okta_help.htm?type=oie&id=ext-about-osop) and [Configure a global session policy and an authentication policy](/docs/guides/configure-signon-policy/main/). +A [global session policy](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy) controls who has access and how a user gains access to Okta. See [Global session policies](https://help.okta.com/okta_help.htm?type=oie&id=ext-about-osop) and [Configure a global session policy and an authentication policy](/docs/guides/configure-signon-policy/main/). #### Authentication policies -An [authentication policy](/docs/reference/api/policy/#authentication-policy) determines the extra levels of authentication performed before a user can access an app, such as enforcing factor requirements. See [Authentication policies](https://help.okta.com/okta_help.htm?type=oie&id=ext-about-asop). +An [authentication policy](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy) determines the extra levels of authentication performed before a user can access an app, such as enforcing factor requirements. See [Authentication policies](https://help.okta.com/okta_help.htm?type=oie&id=ext-about-asop). You can create an authentication policy specifically for the app or create a few policies and [share them](https://help.okta.com/okta_help.htm?type=oie&id=ext-share-auth-policy) across multiple apps. @@ -116,7 +116,7 @@ See [Okta account management policy](https://help.okta.com/okta_help.htm?type=oi ### Password policies -A [password policy](/docs/reference/api/policy/#password-policy) determines the requirements for a user's password length and complexity, and how often a user must change their password. Okta provides a default policy to enforce the use of strong passwords. +A [password policy](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy) determines the requirements for a user's password length and complexity, and how often a user must change their password. Okta provides a default policy to enforce the use of strong passwords. See [Configure the password authenticator](https://help.okta.com/okta_help.htm?type=oie&id=ext-configure-password) for more information on passwords as an authenticator factor. @@ -126,17 +126,17 @@ Enrollment policies determine how users enroll an authenticator and what attribu #### Authenticator enrollment policies -An [authenticator enrollment policy](/docs/reference/api/policy/#authenticator-enrollment-policy) controls how users enroll an authenticator. The policy controls which of the multifactor authentication (MFA) [methods](https://help.okta.com/okta_help.htm?type=oie&id=ext-about-authenticators) are available for a user and when a user can enroll in a particular factor. +An [authenticator enrollment policy](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy) controls how users enroll an authenticator. The policy controls which of the multifactor authentication (MFA) [methods](https://help.okta.com/okta_help.htm?type=oie&id=ext-about-authenticators) are available for a user and when a user can enroll in a particular factor. Enable factors in your Okta org by creating a policy with one or more authenticators, and then assigning that policy to your app. See [Authenticators](/docs/guides/authenticators-overview/main/) to learn how to increase the security of your app by requiring a user to verify their identity in more than one way. -> **Note:** In Identity Engine, the Multifactor (MFA) Enrollment Policy name has changed to [authenticator enrollment policy](/docs/reference/api/policy/#authenticator-enrollment-policy). +> **Note:** In Identity Engine, the Multifactor (MFA) Enrollment Policy name has changed to [authenticator enrollment policy](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy). See [Authenticator enrollment policy](https://help.okta.com/okta_help.htm?type=oie&id=ext-about-mfa-enrol-policies) for additional information on MFA authentication, enrollment policies, and rules. #### Profile enrollment policies -The [Profile enrollment policy](/docs/reference/api/policy/#profile-enrollment-policy) collects the attributes required to validate users when they attempt to access your app. Use this policy for [self-service registration](/docs/guides/oie-embedded-sdk-use-case-self-reg/android/main/) or for [progressive enrollment](https://help.okta.com/okta_help.htm?type=oie&id=ext-pe-policies). +The [Profile enrollment policy](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy) collects the attributes required to validate users when they attempt to access your app. Use this policy for [self-service registration](/docs/guides/oie-embedded-sdk-use-case-self-reg/android/main/) or for [progressive enrollment](https://help.okta.com/okta_help.htm?type=oie&id=ext-pe-policies). With self-service registration flows, users register and activate their profiles by clicking a sign-up link in the Sign-In Widget or through a custom-embedded authentication solution. @@ -148,9 +148,9 @@ With progressive enrollment flows, you can capture the minimum user information Identity Threat Protection with Okta AI is an identity threat solution that combines current security practices with continuous real-time risk assessment. See [Identity Threat Protection with Okta AI](https://help.okta.com/okta_help.htm?type=oie&id=ext-itp-overview). Identity Threat Protection uses the entity risk policy and Post auth session evaluation for these threat evaluations. -* [Entity risk policy](/docs/reference/api/policy/#entity-risk-policy): The entity risk policy monitors your org for entity risk changes related to identity-based threats. For Admin Console tasks and further information, see [Entity risk policy](https://help.okta.com/okta_help.htm?type=oie&id=csh-entity-risk-policy). +* [Entity risk policy](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy): The entity risk policy monitors your org for entity risk changes related to identity-based threats. For Admin Console tasks and further information, see [Entity risk policy](https://help.okta.com/okta_help.htm?type=oie&id=csh-entity-risk-policy). -* [Post auth session evaluation](/docs/reference/api/policy/#post-auth-session-evaluation-policy): Post auth session evaluation monitors user sessions on your org to identify changes in session context. For Admin Console tasks and further information, see [Post auth session evaluation](https://help.okta.com/okta_help.htm?type=oie&id=csh-continuous-access-evaluation). +* [Post auth session evaluation](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy): Post auth session evaluation monitors user sessions on your org to identify changes in session context. For Admin Console tasks and further information, see [Post auth session evaluation](https://help.okta.com/okta_help.htm?type=oie&id=csh-continuous-access-evaluation). ### API access policies @@ -158,7 +158,7 @@ An [OAuth Authorization Policy](https://developer.okta.com/docs/api/openapi/okta ### Route to other identity providers -The [IdP Discovery Policy](/docs/reference/api/policy/#idp-discovery-policy) determines where to route users when they attempt to sign in to your org. You can route users to various [identity providers](/docs/guides/add-an-external-idp/). +The [IdP Discovery Policy](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy) determines where to route users when they attempt to sign in to your org. You can route users to various [identity providers](/docs/guides/add-an-external-idp/). > **Note:** This policy isn't for performing authentication or authorization. It's used only to determine where a user is routed. You can't control access with an IdP discovery policy. diff --git a/packages/@okta/vuepress-site/docs/guides/build-custom-ui-mobile/main/index.md b/packages/@okta/vuepress-site/docs/guides/build-custom-ui-mobile/main/index.md index 4a9c34265e7..d4c255797bb 100644 --- a/packages/@okta/vuepress-site/docs/guides/build-custom-ui-mobile/main/index.md +++ b/packages/@okta/vuepress-site/docs/guides/build-custom-ui-mobile/main/index.md @@ -68,7 +68,7 @@ Every authentication transaction starts with primary authentication, which valid > **Note:** Custom sign-in only works with [Org MFA](/docs/guides/mfa/sms/main/#set-up-your-org-for-mfa). This means that before you exchange the session token for an access token, you must ensure that [App-Level MFA](https://help.okta.com/okta_help.htm?id=ext_MFA_App_Level) is disabled for the application. -> **Note:** In Identity Engine, the MFA Enrollment Policy name has changed to [authenticator enrollment policy](/docs/reference/api/policy/#authenticator-enrollment-policy). +> **Note:** In Identity Engine, the MFA Enrollment Policy name has changed to [authenticator enrollment policy](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy). diff --git a/packages/@okta/vuepress-site/docs/guides/configure-signon-policy/main/index.md b/packages/@okta/vuepress-site/docs/guides/configure-signon-policy/main/index.md index f34fe7c68f7..71bb0caa0bd 100644 --- a/packages/@okta/vuepress-site/docs/guides/configure-signon-policy/main/index.md +++ b/packages/@okta/vuepress-site/docs/guides/configure-signon-policy/main/index.md @@ -40,7 +40,7 @@ Global session policies help control who can have access and how a user gains ac #### Multiple options -You can configure a global session policy to require any of the [factors that you set up](https://help.okta.com/okta_help.htm?type=oie&id=csh-configure-authenticators). Then use the primary and secondary factor conditions in a rule to define which factors are evaluated. For example, add a rule that prompts for more factors when you want only users who are inside your [corporate network](/docs/reference/api/policy/#network-condition-object) to have access. +You can configure a global session policy to require any of the [factors that you set up](https://help.okta.com/okta_help.htm?type=oie&id=csh-configure-authenticators). Then use the primary and secondary factor conditions in a rule to define which factors are evaluated. For example, add a rule that prompts for more factors when you want only users who are inside your [corporate network](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicyRule!path=0/conditions/network&t=request) to have access. > **Note:** If you select **Any factor used to meet the Authentication Policy requirements**, you remove the global password requirement from the global session policy. This transfers responsibility for defining and enforcing authentication to each of your [authentication policies](#authentication-policies) instead. See [Configure passwordless authentication](https://help.okta.com/okta_help.htm?type=oie&id=ext-passwordless-auth). @@ -98,7 +98,7 @@ Configure a global session policy to prompt a user for a factor [authenticator]( 1. Click **Set time limit** and leave the default time settings. - > **Note:** You can also set the [maximum session lifetime value](/docs/reference/api/policy/#signon-session-object) using the Okta APIs. If you previously set this value using the API, you can't exceed that maximum in the Admin Console. Setting a value over the API maximum results in an error. + > **Note:** You can also set the [maximum session lifetime value](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicyRule!path=4/actions/signon/session/maxSessionLifetimeMinutes&t=request) using the Okta APIs. If you previously set this value using the API, you can't exceed that maximum in the Admin Console. Setting a value over the API maximum results in an error. 1. Click **Create Rule**. @@ -181,5 +181,5 @@ In this example, create a policy that allows a specific group, **Full time emplo ## See also * [Policies concept](/docs/concepts/policies/) -* [Policy API reference](/docs/reference/api/policy/) +* [Policy API reference](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy) * [Configure an access policy](/docs/guides/configure-access-policy/) diff --git a/packages/@okta/vuepress-site/docs/guides/delete-all-stay-signed-in-sessions/main/index.md b/packages/@okta/vuepress-site/docs/guides/delete-all-stay-signed-in-sessions/main/index.md index 61aab2da7bf..f3402d0f61e 100644 --- a/packages/@okta/vuepress-site/docs/guides/delete-all-stay-signed-in-sessions/main/index.md +++ b/packages/@okta/vuepress-site/docs/guides/delete-all-stay-signed-in-sessions/main/index.md @@ -54,7 +54,7 @@ The difference between persistent SSO and session SSO is that you can maintain p ### Enable the parameter -To enable persistent SSO for **Stay signed in**, you need to update the [`usePersistentCookie`](/docs/reference/api/policy/#signon-action-object) parameter in the appropriate global session policy. These steps use the Okta [Policy Postman collection](/docs/reference/postman-collections/) to enable the parameter. +To enable persistent SSO for **Stay signed in**, you need to update the [`usePersistentCookie`](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicyRule!path=4/actions/signon/session/usePersistentCookie&t=request) parameter in the appropriate global session policy. These steps use the Okta [Policy Postman collection](/docs/reference/postman-collections/) to enable the parameter. Before you begin, complete the following steps: diff --git a/packages/@okta/vuepress-site/docs/guides/oie-upgrade-api-sdk-to-oie-sdk/main/index.md b/packages/@okta/vuepress-site/docs/guides/oie-upgrade-api-sdk-to-oie-sdk/main/index.md index 27ccd6abd0b..778a28db08e 100644 --- a/packages/@okta/vuepress-site/docs/guides/oie-upgrade-api-sdk-to-oie-sdk/main/index.md +++ b/packages/@okta/vuepress-site/docs/guides/oie-upgrade-api-sdk-to-oie-sdk/main/index.md @@ -185,7 +185,7 @@ If your app uses direct APIs for a multifactor authentication flow, your code ma - `/api/authn/factors/{emailFactorId}/verify`: Send the user an email with a sign-in code - `/api/authn/factors/{$emailFactorId}/verify`: Call this a second time with the sign-in code from the email challenge ->**Note:** If you call the direct `/api/v1/policies` API to manage or update MFA enrollment policies, you need to update these calls to use Identity Engine policies. See [Authentication policy](/docs/reference/api/policy/#authentication-policy) and [Profile enrollment policy](/docs/reference/api/policy/#profile-enrollment-policy). +>**Note:** If you call the direct `/api/v1/policies` API to manage or update MFA enrollment policies, you need to update these calls to use Identity Engine policies. See [Authentication policy](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy) and [Profile enrollment policy](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy). See the following sample calls and responses for the MFA authentication flow using the email factor: diff --git a/packages/@okta/vuepress-site/docs/guides/oie-upgrade-mfa-enroll-policy/main/index.md b/packages/@okta/vuepress-site/docs/guides/oie-upgrade-mfa-enroll-policy/main/index.md index 2bd0ab7aa71..b2ae208a432 100644 --- a/packages/@okta/vuepress-site/docs/guides/oie-upgrade-mfa-enroll-policy/main/index.md +++ b/packages/@okta/vuepress-site/docs/guides/oie-upgrade-mfa-enroll-policy/main/index.md @@ -14,7 +14,7 @@ Okta Identity Engine sets apart factors and authenticators to align with industr - Identity Engine uses authenticators in the settings for its authenticator enrollment policy. - Classic Engine uses factors in the settings for its multifactor (MFA) enrollment policy. -In Identity Engine, the MFA Enrollment Policy name has changed to [authenticator enrollment policy](/docs/reference/api/policy/#authenticator-enrollment-policy). Classic Engine still refers to the same policy as the [Multifactor (MFA) Enrollment Policy](/docs/reference/api/policy/#multifactor-mfa-enrollment-policy). In the API, the policy type of `MFA_ENROLL` remains unchanged, however, the `settings` data contains authenticator or factors, depending on the configuration. +In Identity Engine, the MFA Enrollment Policy name has changed to [authenticator enrollment policy](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy). Classic Engine still refers to the same policy as the [Multifactor (MFA) Enrollment Policy](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy). In the API, the policy type of `MFA_ENROLL` remains unchanged, however, the `settings` data contains authenticator or factors, depending on the configuration. After you upgrade your org to Identity Engine, consider the following: @@ -26,15 +26,15 @@ After you upgrade your org to Identity Engine, consider the following: > **Note:** Whether you edit the authenticator enrollment policy, when you click **Update Policy** in the Admin Console, the factor-to-authenticator conversion occurs. -Existing code that manages and uses authenticator enrollment policies through the [Policy API](/docs/reference/api/policy/) requires some development work. After you upgrade your org, address the factor-to-authenticator conversion schema changes. +Existing code that manages and uses authenticator enrollment policies through the [Policy API](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy) requires some development work. After you upgrade your org, address the factor-to-authenticator conversion schema changes. This guide provides key API considerations to upgrade your app for multifactor enrollment flows in Identity Engine. ## Authenticator enrollment policy API changes in Identity Engine -The following are the main behavior changes to the [authenticator enrollment policy](/docs/reference/api/policy/#authenticator-enrollment-policy) in Identity Engine: +The following are the main behavior changes to the [authenticator enrollment policy](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy) in Identity Engine: -- The Policy API supports both factors and authenticator schemas in the [settings](/docs/reference/api/policy/#policy-settings-data-2) for the authenticator enrollment policy. +- The Policy API supports both factors and authenticator schemas in the [settings](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy!path=2/settings/authenticators&t=request) for the authenticator enrollment policy. - New authenticator enrollment policies contain either factors or authenticators in their settings (they’re mutually exclusive). - Existing authenticator enrollment policies (that is, policies created before the Identity Engine upgrade) still contain factors in their settings. - Authenticator enrollment policies modified from the Admin Console of an Identity Engine org have their factors converted to authenticators in their settings. @@ -49,17 +49,17 @@ Both the password policy and the authenticator enrollment policy govern the enro > **Note:** Password policy recovery authenticator settings supersede the authenticator enrollment policy settings. For example, if the phone authenticator is `Optional` or `Disabled` for the authenticator enrollment policy, but `Required` for the password policy, then phone enrollment is required for the password recovery flow. -See [password policy](/docs/reference/api/policy/#password-policy) and [Configure password policies](https://help.okta.com/okta_help.htm?type=oie&id=csh-configure-password) for details on how to configure the password policy in the Admin Console. +See [password policy](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy) and [Configure password policies](https://help.okta.com/okta_help.htm?type=oie&id=csh-configure-password) for details on how to configure the password policy in the Admin Console. ## Get authenticator enrollment policies -To parse a response from the `GET /api/v1/policies?type=MFA_ENROLL` request, you must determine if the returned authenticator enrollment policy contains either `authenticators` or `factors` in the [settings schema](/docs/reference/api/policy/#policy-settings-data-2). +To parse a response from the `GET /api/v1/policies?type=MFA_ENROLL` request, you must determine if the returned authenticator enrollment policy contains either `authenticators` or `factors` in the [settings schema](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy!path=2/settings&t=request). -> **Note:** Another indicator of an authenticator-based enrollment policy is when `type=AUTHENTICATORS` in the [settings schema](/docs/reference/api/policy/#policy-settings-data-2). The `type` property could be absent from the response of factor-based authenticator enrollment policies. +> **Note:** Another indicator of an authenticator-based enrollment policy is when `type=AUTHENTICATORS` in the [settings schema](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy!path=2/settings&t=request). The `type` property could be absent from the response of factor-based authenticator enrollment policies. -If the returned policy uses `authenticators`, loop through the list of [Policy Authenticator objects](/docs/reference/api/policy/#policy-authenticator-object) and use the `key` property to identify the authenticator. See the [Authenticators API](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Authenticator/) for more details on the available authenticators in your org. +If the returned policy uses `authenticators`, loop through the list of [Policy Authenticator objects](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy!path=2/settings/authenticators/key&t=request) and use the `key` property to identify the authenticator. See the [Authenticators API](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Authenticator/) for more details on the available authenticators in your org. -If the returned policy uses `factors`, you need to loop through every type of [Policy Factor Configuration object](/docs/reference/api/policy/#policy-factors-configuration-object), as you've done previously for your app. +If the returned policy uses `factors`, you need to loop through every type of [Policy Factor Configuration object](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy!path=2/settings/type&t=request), as you've done previously for your app. Response example of an authenticator enrollment policy `settings` snippet with authenticators: @@ -110,25 +110,25 @@ Response example of an authenticator enrollment policy `settings` snippet with f ## Create an authenticator enrollment policy -To create an authenticator enrollment policy through the [Policy API](/docs/reference/api/policy/), you need to provide the `settings` schema with either the list of [Policy Authenticator objects](/docs/reference/api/policy/#policy-authenticator-object) or [Policy Factors Configuration objects](/docs/reference/api/policy/#policy-factors-configuration-object) in the `POST /api/v1/policies` request body parameters. +To create an authenticator enrollment policy through the [Policy API](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy), you need to provide the `settings` schema with either the list of [Policy Authenticator objects](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy!path=2/settings/authenticators/constraints&t=request) or [Policy Factors Configuration objects](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy!path=2/settings&t=request) in the `POST /api/v1/policies` request body parameters. -To create an authenticator enrollment policy in Identity Engine, use the [Policies API](/docs/reference/api/policy/#create-a-policy). To set the list of authenticators for the policy, use the [Authenticators API](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Authenticator/#tag/Authenticator/operation/listAuthenticators). +To create an authenticator enrollment policy in Identity Engine, use the [Policies API](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy). To set the list of authenticators for the policy, use the [Authenticators API](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Authenticator/#tag/Authenticator/operation/listAuthenticators). -You can also create an authenticator enrollment policy with factors instead of authenticators to support legacy systems or workflows. Set the policy `settings` to the factors schema with the [Policy Factors Configuration object](/docs/reference/api/policy/#policy-factors-configuration-object). +You can also create an authenticator enrollment policy with factors instead of authenticators to support legacy systems or workflows. Set the policy `settings` to the factors schema with the [Policy Factors Configuration object](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy!path=2/settings/authenticators/constraints&t=request). -> **Note:** Configure the other policy parameters according to the [Create a Policy](/docs/reference/api/policy/#create-a-policy) API operation. Specifically, you need to include the `type=MFA_ENROLL` parameter for an authenticator enrollment policy. +> **Note:** Configure the other policy parameters according to the [Create a Policy](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy) API operation. Specifically, you need to include the `type=MFA_ENROLL` parameter for an authenticator enrollment policy. ## Update an authenticator enrollment policy -To update an authenticator enrollment policy through the [Update a Policy](/docs/reference/api/policy/#update-a-policy) API operation, you need to provide the `settings` schema with either the list of [Policy Authenticator objects](/docs/reference/api/policy/#policy-authenticator-object) or [Policy Factors Configuration objects](/docs/reference/api/policy/#policy-factors-configuration-object) in the `PUT /api/v1/policies/{policyId}` request body parameters. +To update an authenticator enrollment policy through the [Update a Policy](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/replacePolicy) API operation, you need to provide the `settings` schema with either the list of [Policy Authenticator objects](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/replacePolicy) or [Policy Factors Configuration objects](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/replacePolicy) in the `PUT /api/v1/policies/{policyId}` request body parameters. -> **Note:** Configure the other policy parameters according to the [Update a Policy](/docs/reference/api/policy/#update-a-policy) API operation. This section focuses on the `settings` parameter required specifically for the authenticator enrollment policy. +> **Note:** Configure the other policy parameters according to the [Update a Policy](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/replacePolicy) API operation. This section focuses on the `settings` parameter required specifically for the authenticator enrollment policy. If you need to convert an existing factor-based authenticator enrollment policy to use authenticators, then update the policy with authenticators in the `settings` parameter. Use the [Policy Factors Configuration object and Authenticator keys mapping](#policy-factors-configuration-object-and-authenticator-keys-mapping) table to map Policy Factors Configuration objects to authenticator keys. See the [settings conversion example](#authenticator-enrollment-policy-settings-conversion-example). You can revert to the factor-based authenticator enrollment policy model. Modify an existing authenticator-based enrollment policy to a factored one. To convert the authenticator keys to Policy Factor Configuration objects, see the following: -* [Policy Factors Configuration objects](/docs/reference/api/policy/#policy-factors-configuration-object) +* [Policy Factors Configuration objects](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy!path=2/settings&t=request) * [Policy Factors Configuration object and Authenticator keys mapping](#policy-factors-configuration-object-and-authenticator-keys-mapping) > **Note:** Your app might be integrated with systems like Terraform that you can't update to parse the authenticators-based enrollment policy. If so, revert your policy to use factors instead of authenticators. diff --git a/packages/@okta/vuepress-site/docs/reference/api/policy/index.md b/packages/@okta/vuepress-site/docs/reference/api/policy/index.md index 0bc4facc756..2212d244694 100644 --- a/packages/@okta/vuepress-site/docs/reference/api/policy/index.md +++ b/packages/@okta/vuepress-site/docs/reference/api/policy/index.md @@ -5,6 +5,13 @@ category: management # Policy API +The Policy API reference is now available at the new [Okta API reference portal](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy). + +Explore the [Okta Public API Collections](https://www.postman.com/okta-eng/workspace/okta-public-api-collections/overview) workspace to get started with the ${apiName} API Postman collection. + +https://developer.okta.com/docs/reference/api/policy/ + + + + - + - + From 2cfea5b30012b1fe969874fc91ebbd65be9540bb Mon Sep 17 00:00:00 2001 From: Thomas Cavanagh Date: Tue, 10 Sep 2024 17:49:23 -0400 Subject: [PATCH 2/8] Second pass of links --- packages/@okta/vuepress-site/conductor.yml | 10 +++++----- .../archive-configure-signon-policy/main/index.md | 2 +- .../docs/reference/core-okta-api/index.md | 2 +- .../docs/reference/password-hook/index.md | 2 +- .../release-notes/2023-okta-identity-engine/index.md | 10 +++++----- .../vuepress-site/docs/release-notes/2023/index.md | 2 +- .../release-notes/2024-okta-identity-engine/index.md | 4 ++-- 7 files changed, 16 insertions(+), 16 deletions(-) diff --git a/packages/@okta/vuepress-site/conductor.yml b/packages/@okta/vuepress-site/conductor.yml index 46902dc186a..15463e486ce 100644 --- a/packages/@okta/vuepress-site/conductor.yml +++ b/packages/@okta/vuepress-site/conductor.yml @@ -108,7 +108,7 @@ redirects: - from: /reference/authentication_reference to: /docs/reference/api/oidc/index.html - from: /docs/getting_started/policy.html - to: /docs/reference/api/policy/index.html + to: https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/ - from: /docs/api/rest/sessions.html to: /docs/reference/api/sessions/ - from: /docs/api/rest/templates.html @@ -476,7 +476,7 @@ redirects: - from: /docs/api/resources/linked-objects/index.html to: /docs/reference/api/linked-objects/ - from: /docs/api/resources/policy/index.html - to: /docs/reference/api/policy/ + to: https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/ - from: /docs/api/resources/schemas/index.html to: https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Schema/ - from: /docs/api/resources/sessions/index.html @@ -804,7 +804,7 @@ redirects: - from: /docs/api/resources/linked-objects to: /docs/reference/api/linked-objects/ - from: /docs/api/resources/policy - to: /docs/reference/api/policy/ + to: https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/ - from: /docs/api/resources/schemas to: https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Schema/ - from: /docs/api/resources/sessions @@ -906,7 +906,7 @@ redirects: - from: /docs/api/resources/linked-objects.html to: /docs/reference/api/linked-objects/ - from: /docs/api/resources/policy.html - to: /docs/reference/api/policy/ + to: https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/ - from: /docs/api/resources/schemas.html to: https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Schema/ - from: /docs/api/resources/system_log.html @@ -2308,7 +2308,7 @@ redirects: - from: /docs/guides/password-import-hook/-/next-steps/index.html to: /docs/guides/password-import-inline-hook/nodejs/main/#test-your-hook - from: /docs/reference/api/oie-policy-types/index.html - to: /docs/reference/api/policy/ + to: https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/ - from: /docs/concepts/ie-intro/index.html to: https://help.okta.com/oie/en-us/okta_help_CSH.htm#ext-get-started-oie - from: /docs/concepts/ie-intro diff --git a/packages/@okta/vuepress-site/docs/guides/archive-configure-signon-policy/main/index.md b/packages/@okta/vuepress-site/docs/guides/archive-configure-signon-policy/main/index.md index 5837ffa0669..3784ea03e9e 100644 --- a/packages/@okta/vuepress-site/docs/guides/archive-configure-signon-policy/main/index.md +++ b/packages/@okta/vuepress-site/docs/guides/archive-configure-signon-policy/main/index.md @@ -28,7 +28,7 @@ This guide explains how to add and configure Okta sign-on policies and app sign- An Okta sign-on policy helps you control who can sign in and how a user is allowed to sign in to Okta, including whether they are challenged for MFA and how long they are allowed to remain signed in before re-authenticating. Additionally, you can configure app sign-on policies for each application for extra levels of authentication that you may want performed before an application can be accessed. -Add a rule to the Okta sign-on policy, for example, when you need to make sure that only users who are inside your [corporate network](/docs/reference/api/policy/#network-condition-object) can access your application, or you need to exclude certain roles in your organization from accessing it. Add a rule for an app sign-on policy, for example, to prompt groups that are assigned to your app to re-authenticate after 60 minutes. There is only one app sign-on policy, but you can add as many rules to it as you need. +Add a rule to the Okta sign-on policy, for example, when you need to make sure that only users who are inside your [corporate network](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicyRule!path=8/conditions/network&t=request) can access your application, or you need to exclude certain roles in your organization from accessing it. Add a rule for an app sign-on policy, for example, to prompt groups that are assigned to your app to re-authenticate after 60 minutes. There is only one app sign-on policy, but you can add as many rules to it as you need. You can specify any number of Okta sign-on policies and the order in which they are executed. If a policy in the list doesn't apply to the user trying to sign in, the system moves to the next policy. There is one required organization-wide policy named **Default**. By definition, the Default policy applies to all users. diff --git a/packages/@okta/vuepress-site/docs/reference/core-okta-api/index.md b/packages/@okta/vuepress-site/docs/reference/core-okta-api/index.md index 7d88273293b..cc4d7187851 100644 --- a/packages/@okta/vuepress-site/docs/reference/core-okta-api/index.md +++ b/packages/@okta/vuepress-site/docs/reference/core-okta-api/index.md @@ -23,7 +23,7 @@ REST endpoints to configure objects whenever you need. For example: - The [Apps API](/docs/reference/api/apps/) is used to manage Apps and their association with Users and Groups. - The [Users API](/docs/reference/api/users) is used for CRUD operations on Users. - The [Sessions API](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Session/) creates and manages user's authentication sessions. -- The [Policy API](/docs/reference/api/policy/) creates and manages settings such as a user's session lifetime. +- The [Policy API](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy) creates and manages settings such as a user's session lifetime. - The [Factors API](/docs/reference/api/factors/) is used to enroll, manage, and verify factors for multi-factor authentication (MFA). - The [Devices API](/docs/reference/api/devices) is used to manage Device identity and lifecycle. diff --git a/packages/@okta/vuepress-site/docs/reference/password-hook/index.md b/packages/@okta/vuepress-site/docs/reference/password-hook/index.md index 08270594256..fdc76960e0f 100644 --- a/packages/@okta/vuepress-site/docs/reference/password-hook/index.md +++ b/packages/@okta/vuepress-site/docs/reference/password-hook/index.md @@ -25,7 +25,7 @@ The password import inline hook is triggered when the end user tries to sign in If your service returns a response that indicates that the password is valid, Okta sets the password for the user and won't normally need to call your service again. However, if your Okta org is in read-only mode, it might not be possible to set the password. Okta then needs to call your external service again when the end user attempts to signs in. See [Password inline hook and Okta read-only mode](#password-inline-hook-and-okta-read-only-mode) and [Removing Password from Existing User Store](#removing-password-from-existing-user-store) for details. ->**Note:** Password policies do not apply to the password import inline hook. That is, if your external service validates the password, the password imports even if it does not meet the Okta [password policy](/docs/reference/api/policy/#password-policy) requirements. +>**Note:** Password policies do not apply to the password import inline hook. That is, if your external service validates the password, the password imports even if it does not meet the Okta [password policy](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy!path=4/type&t=request) requirements. ## Objects in the request from Okta diff --git a/packages/@okta/vuepress-site/docs/release-notes/2023-okta-identity-engine/index.md b/packages/@okta/vuepress-site/docs/release-notes/2023-okta-identity-engine/index.md index 4b0dc1bc366..4be4fd3d0d4 100644 --- a/packages/@okta/vuepress-site/docs/release-notes/2023-okta-identity-engine/index.md +++ b/packages/@okta/vuepress-site/docs/release-notes/2023-okta-identity-engine/index.md @@ -250,7 +250,7 @@ Users now receive an authentication challenge for each redirect sent to an Ident Direct authentication out-of-band (OOB) and multifactor out-of-band (MFA OOB) grant flows now support number challenge for Okta Verify Push. See the [MFA OOB grant](/docs/guides/configure-direct-auth-grants/dmfaoobov/main/) and [OOB grant](/docs/guides/configure-direct-auth-grants/coobov/main/) flows. #### Policy Simulation API is GA in Preview -With the Policy API `/simulate` endpoint, you can quickly and easily test policies and validate whether your desired security outcomes are achieved. This endpoint allows you to simulate user access attributes, such as IP address, device, risk, and so on, to test whether the user is granted access to the specified application. This endpoint is implemented in the Admin Console as the [Access Testing Tool](https://help.okta.com/oie/en-us/Content/Topics/identity-engine/policies/access-testing-tool.htm). The `/simulate` endpoint helps you identify potential security risks and compliance issues before you implement a policy. See the [Policy API](/docs/reference/api/policy/#policy-simulation-operations) and [Test your policies with access simulations](/docs/guides/policy-simulation). +With the Policy API `/simulate` endpoint, you can quickly and easily test policies and validate whether your desired security outcomes are achieved. This endpoint allows you to simulate user access attributes, such as IP address, device, risk, and so on, to test whether the user is granted access to the specified application. This endpoint is implemented in the Admin Console as the [Access Testing Tool](https://help.okta.com/oie/en-us/Content/Topics/identity-engine/policies/access-testing-tool.htm). The `/simulate` endpoint helps you identify potential security risks and compliance issues before you implement a policy. See the [Policy API](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicySimulation) and [Test your policies with access simulations](/docs/guides/policy-simulation). #### Developer documentation update in 2023.09.0 @@ -302,7 +302,7 @@ You can now create custom admin roles with permissions to view and manage device * Federated users were unable to sign in to an app due to incorrect AMR value mapping when **Trust AMR claims from this Identity Provider** was enabled. (OKTA-604248) * Removing the `emailAuthenticationLink` variable from the email template didn't update the Sign-In Widget. (OKTA-627533) * OpenID Connect `/token` requests using the SAML 2.0 Assertion grant type flow failed if the SAML assertion expiry was greater than 30 days. (OKTA-632131) -* The Access Testing Tool ([Policy simulation operations](/docs/reference/api/policy/#policy-simulation-operations)) results showed an incorrect value for the profile enrollment self-service registration option. (OKTA-635787) +* The Access Testing Tool ([Policy simulation operations](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicySimulation)) results showed an incorrect value for the profile enrollment self-service registration option. (OKTA-635787) ### Monthly release 2023.08.0 @@ -331,7 +331,7 @@ Users now receive an authentication challenge for each redirect sent to an Ident #### Policy Simulation API is GA in Preview -With the Policy API `/simulate` endpoint, you can quickly and easily test policies and validate whether your desired security outcomes are achieved. This endpoint allows you to simulate user access attributes, such as IP address, device, risk, and so on, to test whether the user is granted access to the specified application. This endpoint is implemented in the Admin Console as the [Access Testing Tool](https://help.okta.com/oie/en-us/Content/Topics/identity-engine/policies/access-testing-tool.htm). The `/simulate` endpoint helps you identify potential security risks and compliance issues before you implement a policy. See the [Policy API](/docs/reference/api/policy/#policy-simulation-operations) and [Test your policies with access simulations](/docs/guides/policy-simulation). +With the Policy API `/simulate` endpoint, you can quickly and easily test policies and validate whether your desired security outcomes are achieved. This endpoint allows you to simulate user access attributes, such as IP address, device, risk, and so on, to test whether the user is granted access to the specified application. This endpoint is implemented in the Admin Console as the [Access Testing Tool](https://help.okta.com/oie/en-us/Content/Topics/identity-engine/policies/access-testing-tool.htm). The `/simulate` endpoint helps you identify potential security risks and compliance issues before you implement a policy. See the [Policy API](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicySimulation) and [Test your policies with access simulations](/docs/guides/policy-simulation). #### Developer documentation updates in 2023.08.0 @@ -483,7 +483,7 @@ The Policy API Self-Service Password Reset object can now use Google Authenticat #### Policy Simulation API is EA in Preview -With the Policy API `/simulate` endpoint, you can quickly and easily test policies and validate whether your desired security outcomes will be achieved. This endpoint allows you to simulate user access attributes, such as IP address, device, risk, and so on, to test whether the user will be granted access to the specified application. This endpoint is implemented in the Admin Console as the [Access Testing Tool](https://help.okta.com/okta_help.htm?type=oie&id=csh-access-testing-tool). The`/simulate` endpoint helps you identify potential security risks and compliance issues before you implement a policy. See [Policy API](/docs/reference/api/policy/#policy-simulation-operations) and [Test your policies with access simulations](/docs/guides/policy-simulation/). +With the Policy API `/simulate` endpoint, you can quickly and easily test policies and validate whether your desired security outcomes will be achieved. This endpoint allows you to simulate user access attributes, such as IP address, device, risk, and so on, to test whether the user will be granted access to the specified application. This endpoint is implemented in the Admin Console as the [Access Testing Tool](https://help.okta.com/okta_help.htm?type=oie&id=csh-access-testing-tool). The`/simulate` endpoint helps you identify potential security risks and compliance issues before you implement a policy. See [Policy API](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicySimulation) and [Test your policies with access simulations](/docs/guides/policy-simulation/). #### Universal Directory attribute and enum limits are GA in Production @@ -491,7 +491,7 @@ Universal Directory now has limits to the number of attributes per org and the n #### Developer documentation update in 2023.06.0 -A new policy testing guide is available to demonstrate a new Policy API endpoint used to test access policies. This feature is also available in the Admin Console > Reports as the Access Testing Tool. See the new [simulate endpoint](/docs/reference/api/policy/#policy-simulation-operations) in the API reference and [Test your policies with access simulations](/docs/guides/policy-simulation). +A new policy testing guide is available to demonstrate a new Policy API endpoint used to test access policies. This feature is also available in the Admin Console > Reports as the Access Testing Tool. See the new [simulate endpoint](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicySimulation) in the API reference and [Test your policies with access simulations](/docs/guides/policy-simulation). #### Bugs fixed in 2023.06.0 diff --git a/packages/@okta/vuepress-site/docs/release-notes/2023/index.md b/packages/@okta/vuepress-site/docs/release-notes/2023/index.md index 1a49e20845c..c5db0b9084c 100644 --- a/packages/@okta/vuepress-site/docs/release-notes/2023/index.md +++ b/packages/@okta/vuepress-site/docs/release-notes/2023/index.md @@ -228,7 +228,7 @@ Users now receive an authentication challenge for each redirect sent to an Ident #### Policy Simulation API is GA in Preview -With the Policy API `/simulate` endpoint, you can quickly and easily test policies and validate whether your desired security outcomes are achieved. This endpoint allows you to simulate user access attributes, such as IP address, device, risk, and so on, to test whether the user is granted access to the specified application. This endpoint is implemented in the Admin Console as the [Access Testing Tool](https://help.okta.com/oie/en-us/Content/Topics/identity-engine/policies/access-testing-tool.htm). The `/simulate` endpoint helps you identify potential security risks and compliance issues before you implement a policy. See the [Policy API](/docs/reference/api/policy/#policy-simulation-operations) and [Test your policies with access simulations](/docs/guides/policy-simulation). +With the Policy API `/simulate` endpoint, you can quickly and easily test policies and validate whether your desired security outcomes are achieved. This endpoint allows you to simulate user access attributes, such as IP address, device, risk, and so on, to test whether the user is granted access to the specified application. This endpoint is implemented in the Admin Console as the [Access Testing Tool](https://help.okta.com/oie/en-us/Content/Topics/identity-engine/policies/access-testing-tool.htm). The `/simulate` endpoint helps you identify potential security risks and compliance issues before you implement a policy. See the [Policy API](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicySimulation) and [Test your policies with access simulations](/docs/guides/policy-simulation). #### Developer documentation update in 2023.08.0 diff --git a/packages/@okta/vuepress-site/docs/release-notes/2024-okta-identity-engine/index.md b/packages/@okta/vuepress-site/docs/release-notes/2024-okta-identity-engine/index.md index 2c9c2a61d85..47d280eadc1 100644 --- a/packages/@okta/vuepress-site/docs/release-notes/2024-okta-identity-engine/index.md +++ b/packages/@okta/vuepress-site/docs/release-notes/2024-okta-identity-engine/index.md @@ -423,7 +423,7 @@ Certain system log events now contain a new property called `changeDetails` in t #### Multiple Identifiers is EA in Preview -Today, end users must sign in to Okta with a username or email address only. With the Multiple Identifiers feature, admins can configure identifiers, or user attributes from Universal Directory, that an end user can enter to authenticate. Multiplier identifiers work in sign-in, recovery, self-service registration, and unlock flows. Admins can configure up to three identifiers, including email (which is still a required identifier). See [Profile enrollment policy](/docs/reference/api/policy/#profile-enrollment-policy). +Today, end users must sign in to Okta with a username or email address only. With the Multiple Identifiers feature, admins can configure identifiers, or user attributes from Universal Directory, that an end user can enter to authenticate. Multiplier identifiers work in sign-in, recovery, self-service registration, and unlock flows. Admins can configure up to three identifiers, including email (which is still a required identifier). See [Profile enrollment policy](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy!path=5/type&t=request). #### Developer documentation update in 2024.05.0 @@ -506,7 +506,7 @@ Identity Threat Protection with Okta AI is a powerful risk assessment and respon See the [Shared Signals Framework (SSF) Receiver](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/SSFReceiver/) and [SSF SET](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/SSFSecurityEventToken/) APIs. -See also the [Entity risk policy](/docs/reference/api/policy/#entity-risk-policy) and [Continuous Access evaluation policy](/docs/reference/api/policy/#continuous-access-evaluation-policy) API updates. +See also the [Entity risk policy](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy!path=7/type&t=request) and [Continuous Access evaluation policy](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy!path=6/type&t=request) API updates. #### Enhanced app API contracts is GA in Production From 416706d5c8b6a3594cd3478ca843a106dbc7003f Mon Sep 17 00:00:00 2001 From: Thomas Cavanagh Date: Thu, 12 Sep 2024 16:25:14 -0400 Subject: [PATCH 3/8] Finished up links and updated left hand nav and Postman link --- .../archive-configure-signon-policy/main/index.md | 4 ++-- .../okta-account-management-policy/main/index.md | 2 +- .../docs/guides/policy-simulation/main/index.md | 2 +- .../shared-sso-android-ios/main/ios/enablesso.md | 2 +- .../guides/step-up-authentication/main/index.md | 4 ++-- .../docs/reference/api/policy/index.md | 4 +--- .../index.md | 10 ++++++---- .../docs/reference/password-hook/index.md | 2 +- .../2023-okta-identity-engine/index.md | 8 ++++---- .../vuepress-site/docs/release-notes/2023/index.md | 2 +- .../2024-okta-identity-engine/index.md | 14 +++++++------- .../vuepress-theme-prose/const/navbar.const.js | 2 +- 12 files changed, 28 insertions(+), 28 deletions(-) diff --git a/packages/@okta/vuepress-site/docs/guides/archive-configure-signon-policy/main/index.md b/packages/@okta/vuepress-site/docs/guides/archive-configure-signon-policy/main/index.md index 3784ea03e9e..33b3a064201 100644 --- a/packages/@okta/vuepress-site/docs/guides/archive-configure-signon-policy/main/index.md +++ b/packages/@okta/vuepress-site/docs/guides/archive-configure-signon-policy/main/index.md @@ -28,7 +28,7 @@ This guide explains how to add and configure Okta sign-on policies and app sign- An Okta sign-on policy helps you control who can sign in and how a user is allowed to sign in to Okta, including whether they are challenged for MFA and how long they are allowed to remain signed in before re-authenticating. Additionally, you can configure app sign-on policies for each application for extra levels of authentication that you may want performed before an application can be accessed. -Add a rule to the Okta sign-on policy, for example, when you need to make sure that only users who are inside your [corporate network](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicyRule!path=8/conditions/network&t=request) can access your application, or you need to exclude certain roles in your organization from accessing it. Add a rule for an app sign-on policy, for example, to prompt groups that are assigned to your app to re-authenticate after 60 minutes. There is only one app sign-on policy, but you can add as many rules to it as you need. +Add a rule to the Okta sign-on policy, for example, when you need to make sure that only users who are inside your [corporate network](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicyRule!path=0/conditions/network&t=request) can access your application, or you need to exclude certain roles in your organization from accessing it. Add a rule for an app sign-on policy, for example, to prompt groups that are assigned to your app to re-authenticate after 60 minutes. There is only one app sign-on policy, but you can add as many rules to it as you need. You can specify any number of Okta sign-on policies and the order in which they are executed. If a policy in the list doesn't apply to the user trying to sign in, the system moves to the next policy. There is one required organization-wide policy named **Default**. By definition, the Default policy applies to all users. @@ -91,7 +91,7 @@ The following are step-by-step instructions to configure an Okta sign-on policy 9. For this use case example, leave the default **Session Expires After** setting of **2 hours**. Use these fields to specify the maximum idle time before an authentication prompt is triggered. The maximum allowed time for this option is 90 days. This isn't the total connect time. This is idle time before users see a countdown timer at the 5-minute mark of remaining session time. - > **Note:** You can set the [maximum session lifetime value](/docs/reference/api/policy/#signon-session-object) using the Okta APIs. If you previously set this value using the API, you can't exceed that maximum in the UI. Setting a value over the API maximum results in an error. + > **Note:** You can set the [maximum session lifetime value](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicyRule!path=4/actions/signon/session&t=request) using the Okta APIs. If you previously set this value using the API, you can't exceed that maximum in the UI. Setting a value over the API maximum results in an error. 10. Click **Create Rule**. diff --git a/packages/@okta/vuepress-site/docs/guides/okta-account-management-policy/main/index.md b/packages/@okta/vuepress-site/docs/guides/okta-account-management-policy/main/index.md index ba03bd5da60..68884cc94d8 100644 --- a/packages/@okta/vuepress-site/docs/guides/okta-account-management-policy/main/index.md +++ b/packages/@okta/vuepress-site/docs/guides/okta-account-management-policy/main/index.md @@ -108,7 +108,7 @@ The policy allows for the following specific expressions: | ------ | ----------- | ---- | | `accessRequest.{operation}`| `accessRequest` references the access context of the request. `operation` references the account management operation: `enroll`, `unenroll`, `recover`, or `unlockAccount`. | String | | `accessRequest.authenticator.{id}` | `accessRequest` references the access context of the request. `authenticator.id` references an optional authenticator `id`, for example, the `id` of a custom authenticator. | String | -| `accessRequest.authenticator.{key}` | `accessRequest` references the access context of the request. `authenticator.key` references the [authenticator key](/docs/reference/api/policy/#authenticator-key-type-method-and-characteristic-relationships-for-constraints). | String | +| `accessRequest.authenticator.{key}` | `accessRequest` references the access context of the request. `authenticator.key` references the [authenticator key](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicyRule!path=0/actions/appSignOn/verificationMethod/0/constraints&t=request). | String | ### Condition Object example diff --git a/packages/@okta/vuepress-site/docs/guides/policy-simulation/main/index.md b/packages/@okta/vuepress-site/docs/guides/policy-simulation/main/index.md index d0e42565f2d..9b823758ea1 100644 --- a/packages/@okta/vuepress-site/docs/guides/policy-simulation/main/index.md +++ b/packages/@okta/vuepress-site/docs/guides/policy-simulation/main/index.md @@ -26,7 +26,7 @@ If you need a simple app for testing, see [Sign users in to your SPA using the r ## About Policy Simulation -You can use the Policy API to simulate real-world user requests to access an app. In the Admin Console, these simulations are run using the Access Testing Tool available from **Reports** > **Access testing tool**. See [Access Testing Tool](https://help.okta.com/okta_help.htm?type=oie&id=ext-access-test-tool). The API endpoint that underpins this tool is also available for developers to simulate policy configurations and to test app access. For full details on the API endpoint, see the [Policy API reference](/docs/reference/api/policy/#access-simulation). +You can use the Policy API to simulate real-world user requests to access an app. In the Admin Console, these simulations are run using the Access Testing Tool available from **Reports** > **Access testing tool**. See [Access Testing Tool](https://help.okta.com/okta_help.htm?type=oie&id=ext-access-test-tool). The API endpoint that underpins this tool is also available for developers to simulate policy configurations and to test app access. For full details on the API endpoint, see the [Policy API reference](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicySimulation). The policy simulations run access tests based on existing policy configurations and which rules and settings are matched to create the authentication and enrollment requirements. Results of the tests determine individual or group access to an app. You can simulate matches for the following types of policies and rules: diff --git a/packages/@okta/vuepress-site/docs/guides/shared-sso-android-ios/main/ios/enablesso.md b/packages/@okta/vuepress-site/docs/guides/shared-sso-android-ios/main/ios/enablesso.md index e7abac8e108..bb06c1f8e73 100644 --- a/packages/@okta/vuepress-site/docs/guides/shared-sso-android-ios/main/ios/enablesso.md +++ b/packages/@okta/vuepress-site/docs/guides/shared-sso-android-ios/main/ios/enablesso.md @@ -1,4 +1,4 @@ -To enable persistent SSO for iOS apps, you need to update the [`usePersistentCookie`](/docs/reference/api/policy/#signon-action-object) parameter in the appropriate global session policy. These steps use the Okta [Policy Postman collection](/docs/reference/postman-collections/) to enable the parameter. +To enable persistent SSO for iOS apps, you need to update the [`usePersistentCookie`](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicyRule!path=4/actions/signon/session/usePersistentCookie&t=request) parameter in the appropriate global session policy. These steps use the Okta [Policy Postman collection](/docs/reference/postman-collections/) to enable the parameter. Before you begin, be sure to: diff --git a/packages/@okta/vuepress-site/docs/guides/step-up-authentication/main/index.md b/packages/@okta/vuepress-site/docs/guides/step-up-authentication/main/index.md index fb29970bd96..a96eabc36ea 100644 --- a/packages/@okta/vuepress-site/docs/guides/step-up-authentication/main/index.md +++ b/packages/@okta/vuepress-site/docs/guides/step-up-authentication/main/index.md @@ -27,7 +27,7 @@ Users want seamless access to certain resources, but organizations want to incre The `acr_values` parameter refers to authentication context class reference. Each value defines a specific set of assurance level requirements that the protected resource requires from the authentication event associated with the access and ID tokens. -Today an authorization server relies on [authentication policies](/docs/reference/api/policy/#authentication-policy) to authenticate the user. After the user is authenticated, the authorization server evaluates the scopes and the grant types defined for the app, and then issues the tokens. Although this approach works in many situations, there are several circumstances where more is needed. Resource servers (your protected APIs) can require different authentication strengths or elapsed time frames for different use cases. For example, an eCommerce app requires different authentication strengths depending on whether the item being purchased exceeds a certain threshold. Another example is an app that requires a higher level of assurance before making changes to sensitive information. +Today an authorization server relies on [authentication policies](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicyRule) to authenticate the user. After the user is authenticated, the authorization server evaluates the scopes and the grant types defined for the app, and then issues the tokens. Although this approach works in many situations, there are several circumstances where more is needed. Resource servers (your protected APIs) can require different authentication strengths or elapsed time frames for different use cases. For example, an eCommerce app requires different authentication strengths depending on whether the item being purchased exceeds a certain threshold. Another example is an app that requires a higher level of assurance before making changes to sensitive information. Okta has created predefined `acr_values` that are described in the [Predefined parameter values](#predefined-parameter-values) section. You can include one of these values, based on your use case, in the client authorization request to request a different authentication assurance. The authorization server returns an access token and/or an ID token that contains the `acr` claim. This claim conveys information about the level of assurance that the user verified at the time of authentication. The resource server can then validate these parameters to ensure that the user verified the required level of assurance. @@ -45,7 +45,7 @@ In both Identity Engine and Classic Engine, if the user has a session, the previ ### Factor enrollment -If the user hasn't enrolled a factor, during step-up authentication the user is prompted to enroll a factor as long as an [authenticator enrollment policy](/docs/reference/api/policy/#authenticator-enrollment-policy) is configured (or the [Multifactor Enrollment Policy](/docs/reference/api/policy/#multifactor-mfa-enrollment-policy) in Classic Engine). +If the user hasn't enrolled a factor, during step-up authentication the user is prompted to enroll a factor as long as an [authenticator enrollment policy](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicyRule) is configured (or the [Multifactor Enrollment Policy](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicyRule) in Classic Engine). ## Predefined parameter values diff --git a/packages/@okta/vuepress-site/docs/reference/api/policy/index.md b/packages/@okta/vuepress-site/docs/reference/api/policy/index.md index 2212d244694..4550592c14b 100644 --- a/packages/@okta/vuepress-site/docs/reference/api/policy/index.md +++ b/packages/@okta/vuepress-site/docs/reference/api/policy/index.md @@ -7,9 +7,7 @@ category: management The Policy API reference is now available at the new [Okta API reference portal](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy). -Explore the [Okta Public API Collections](https://www.postman.com/okta-eng/workspace/okta-public-api-collections/overview) workspace to get started with the ${apiName} API Postman collection. - -https://developer.okta.com/docs/reference/api/policy/ +Explore the [Okta Public API Collections](https://www.postman.com/okta-eng/workspace/okta-public-api-collections/overview) workspace to get started with the Policies API. +A new `userVerification` property is available for the `constraints` object of the [Policy API](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicyRule!path=0/actions/appSignOn/verificationMethod/0/constraints/possession/userVerification&t=request). This setting can ensure the verification of a possession factor through a PIN or biometrics. #### Bugs fixed in 2023.12.0 @@ -376,7 +376,7 @@ Front-channel Single Logout (SLO) allows a user to sign out of an SLO participat #### Google Authenticator for account recovery is GA in Production -The Policy API Self-Service Password Reset object can now use Google Authenticator to initiate recovery scenarios. Previously, the object could only use the Email, Phone, or Okta Verify authenticators to initiate recovery. This addition enhances the user experience by increasing the number of options available for recovery. See [Policy API](/docs/reference/api/policy/#self-service-password-reset-action-object). +The Policy API Self-Service Password Reset object can now use Google Authenticator to initiate recovery scenarios. Previously, the object could only use the Email, Phone, or Okta Verify authenticators to initiate recovery. This addition enhances the user experience by increasing the number of options available for recovery. See [Policy API](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicyRule!path=1/actions/selfServicePasswordReset&t=request). #### Okta-generated client secret length increase @@ -479,7 +479,7 @@ The [Create User with password import inline hook](/docs/reference/api/users/#cr #### Google Authenticator for account recovery is now EA in Preview -The Policy API Self-Service Password Reset object can now use Google Authenticator to initiate recovery scenarios. Previously, the object could only use the Email, Phone, or Okta Verify authenticators to initiate recovery. This addition enhances the user experience by increasing the number of options available for recovery. See [Policy API](/docs/reference/api/policy/#self-service-password-reset-action-object). +The Policy API Self-Service Password Reset object can now use Google Authenticator to initiate recovery scenarios. Previously, the object could only use the Email, Phone, or Okta Verify authenticators to initiate recovery. This addition enhances the user experience by increasing the number of options available for recovery. See [Policy API](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicyRule!path=1/actions/selfServicePasswordReset&t=request). #### Policy Simulation API is EA in Preview @@ -888,7 +888,7 @@ When an admin used a group limit in an expression that was greater than 100 (for #### Allowlist for FIDO2 (WebAuthn) authenticators is Self-Service EA in Preview -Okta now enables you to manage which FIDO2 WebAuthn authenticators are allowed in your org for new enrollments. This feature allows you to create an allow list of specific FIDO2 WebAuthn authenticators (based on FIDO Metadata Service) that can be used in enrollment policies. This allows admins to have greater control over which authenticators may be used in their orgs and determine which users may access them in a granular way. See `settings.authenticators.constraints` in the `MFA_ENROLL` [Policies API](/docs/reference/api/policy/#policy-authenticator-object). +Okta now enables you to manage which FIDO2 WebAuthn authenticators are allowed in your org for new enrollments. This feature allows you to create an allow list of specific FIDO2 WebAuthn authenticators (based on FIDO Metadata Service) that can be used in enrollment policies. This allows admins to have greater control over which authenticators may be used in their orgs and determine which users may access them in a granular way. See `settings.authenticators.constraints` in the `MFA_ENROLL` [Policies API](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy!path=2/settings/authenticators&t=request). #### Applications API support for SAML metadata attributes diff --git a/packages/@okta/vuepress-site/docs/release-notes/2023/index.md b/packages/@okta/vuepress-site/docs/release-notes/2023/index.md index c5db0b9084c..612d17d7613 100644 --- a/packages/@okta/vuepress-site/docs/release-notes/2023/index.md +++ b/packages/@okta/vuepress-site/docs/release-notes/2023/index.md @@ -822,7 +822,7 @@ OAuth 2.0 Optional Consent provides an optional property that enables a user to #### Password history policy enforced in strict mode is GA in Production -When an admin [updates passwords](/docs/reference/api/users/#update-user) and sets the `strict` parameter to `true`, the [password history policy](/docs/reference/api/policy/#age-object) is now enforced. +When an admin [updates passwords](/docs/reference/api/users/#update-user) and sets the `strict` parameter to `true`, the [password history policy](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy!path=4/settings/password/age&t=request) is now enforced. #### PBKDF2 Hashing Algorithm support is GA in Production diff --git a/packages/@okta/vuepress-site/docs/release-notes/2024-okta-identity-engine/index.md b/packages/@okta/vuepress-site/docs/release-notes/2024-okta-identity-engine/index.md index 47d280eadc1..434f02e832a 100644 --- a/packages/@okta/vuepress-site/docs/release-notes/2024-okta-identity-engine/index.md +++ b/packages/@okta/vuepress-site/docs/release-notes/2024-okta-identity-engine/index.md @@ -65,7 +65,7 @@ In the System Log, the `system.custom_url_domain.verify` and `system.email_domai #### Authentication method chain is self-service EA -With this feature, you can require users to verify with multiple authentication methods in a specified sequence using the `AUTH_METHOD_CHAIN` verification method. You can create multiple authentication method chains in an authentication policy rule to cater to different use cases and scenarios. See [Create a Policy Rule](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicyRule!path=0/actions/appSignOn/verificationMethod&t=request) and [Authentication method chain](https://help.okta.com/okta_help.htm?type=oie&id=csh-auth-method-chain). +With this feature, you can require users to verify with multiple authentication methods in a specified sequence using the `AUTH_METHOD_CHAIN` verification method. You can create multiple authentication method chains in an authentication policy rule to cater to different use cases and scenarios. See [Create a Policy Rule](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy) and [Authentication method chain](https://help.okta.com/okta_help.htm?type=oie&id=csh-auth-method-chain). #### Bug fixed in 2024.08.1 @@ -423,7 +423,7 @@ Certain system log events now contain a new property called `changeDetails` in t #### Multiple Identifiers is EA in Preview -Today, end users must sign in to Okta with a username or email address only. With the Multiple Identifiers feature, admins can configure identifiers, or user attributes from Universal Directory, that an end user can enter to authenticate. Multiplier identifiers work in sign-in, recovery, self-service registration, and unlock flows. Admins can configure up to three identifiers, including email (which is still a required identifier). See [Profile enrollment policy](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy!path=5/type&t=request). +Today, end users must sign in to Okta with a username or email address only. With the Multiple Identifiers feature, admins can configure identifiers, or user attributes from Universal Directory, that an end user can enter to authenticate. Multiplier identifiers work in sign-in, recovery, self-service registration, and unlock flows. Admins can configure up to three identifiers, including email (which is still a required identifier). See [Profile enrollment policy](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy). #### Developer documentation update in 2024.05.0 @@ -506,7 +506,7 @@ Identity Threat Protection with Okta AI is a powerful risk assessment and respon See the [Shared Signals Framework (SSF) Receiver](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/SSFReceiver/) and [SSF SET](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/SSFSecurityEventToken/) APIs. -See also the [Entity risk policy](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy!path=7/type&t=request) and [Continuous Access evaluation policy](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy!path=6/type&t=request) API updates. +See also the [Entity risk policy](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy) and [Continuous Access evaluation policy](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy) API updates. #### Enhanced app API contracts is GA in Production @@ -579,7 +579,7 @@ The Content Security Policy (CSP) feature lets admins control which URLs may be #### New mappings property for Policy API is EA in Preview -A new `mappings` property is available for the `links` object in `GET /api/v1/policies/{policyId}` and `GET /api/v1/policies?type={type}` responses. This property displays links to policy mappings. See [Policy API](/docs/reference/api/policy/#links-object). +A new `mappings` property is available for the `links` object in `GET /api/v1/policies/{policyId}` and `GET /api/v1/policies?type={type}` responses. This property displays links to policy mappings. See [Policy API](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/getPolicy). #### My Account Authenticators API is GA in Production @@ -591,7 +591,7 @@ The [Login.gov IdP configuration](/docs/guides/add-logingov-idp/main/#create-an- #### Granular API policy authenticator controls is GA in Preview -The Authentication Policy API now includes three new `constraints` object parameters that provide precise control over what specific authenticators and methods are displayed to end users. Previously, some authenticators were mapped to the same authenticator `types` and `methods`. The parameters `authenticationMethods` and `excludeAuthenticationMethods` now identify (or exclude) the exact authenticator for both `knowledge` and `possession` constraints. The `required` parameter indicates whether the `knowledge` or `possession` constraints are required by the assurance. See the [Policy API](/docs/reference/api/policy/#constraints). +The Authentication Policy API now includes three new `constraints` object parameters that provide precise control over what specific authenticators and methods are displayed to end users. Previously, some authenticators were mapped to the same authenticator `types` and `methods`. The parameters `authenticationMethods` and `excludeAuthenticationMethods` now identify (or exclude) the exact authenticator for both `knowledge` and `possession` constraints. The `required` parameter indicates whether the `knowledge` or `possession` constraints are required by the assurance. See the [Policy API](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicyRule!path=0/actions/appSignOn/verificationMethod/0/constraints&t=request). #### Externally signed org AS access tokens @@ -722,7 +722,7 @@ The Content Security Policy (CSP) feature lets admins control which URLs may be #### Granular API policy authenticator controls is self-service EA in Preview -The Authentication Policy API now includes three new `constraints` object parameters that provide precise control over what specific authenticators and methods are displayed to end users. Previously, some authenticators were mapped to the same authenticator `types` and `methods`. The parameters `authenticationMethods` and `excludeAuthenticationMethods` now identify (or exclude) the exact authenticator for both `knowledge` and `possession` constraints. The `required` parameter indicates whether the `knowledge` or `possession` constraints are required by the assurance. See the [Policy API](/docs/reference/api/policy/#constraints). +The Authentication Policy API now includes three new `constraints` object parameters that provide precise control over what specific authenticators and methods are displayed to end users. Previously, some authenticators were mapped to the same authenticator `types` and `methods`. The parameters `authenticationMethods` and `excludeAuthenticationMethods` now identify (or exclude) the exact authenticator for both `knowledge` and `possession` constraints. The `required` parameter indicates whether the `knowledge` or `possession` constraints are required by the assurance. See the [Policy API](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicyRule!path=0/actions/appSignOn/verificationMethod/0/constraints&t=request). #### IP restrictions on tokens @@ -778,7 +778,7 @@ The [List all Devices](https://developer.okta.com/docs/api/openapi/okta-manageme #### New possession constraint property available for Policy API is GA in Production -A new `userVerification` property is available for the `constraints` object of the [Policy API](/docs/reference/api/policy/#constraints). This setting can ensure the verification of a possession factor through a PIN or biometrics. +A new `userVerification` property is available for the `constraints` object of the [Policy API](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicyRule!path=0/actions/appSignOn/verificationMethod/0/constraints&t=request). This setting can ensure the verification of a possession factor through a PIN or biometrics. #### Read-only permission for admin role assignments is GA in Production diff --git a/packages/@okta/vuepress-theme-prose/const/navbar.const.js b/packages/@okta/vuepress-theme-prose/const/navbar.const.js index 300881d0b94..461ad68b5ae 100644 --- a/packages/@okta/vuepress-theme-prose/const/navbar.const.js +++ b/packages/@okta/vuepress-theme-prose/const/navbar.const.js @@ -1031,7 +1031,7 @@ export const reference = [ { title: "MyAccount", path: "https://developer.okta.com/docs/api/openapi/okta-myaccount/guides/overview/" }, { title: "Network Zones", path: "https://developer.okta.com/docs/api/openapi/okta-management/management/tag/NetworkZone/" }, { title: "Org", path: "/docs/reference/api/org/" }, - { title: "Policy", path: "/docs/reference/api/policy/" }, + { title: "Policy", path: "https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/" }, { title: "Principal Rate Limits", path: "https://developer.okta.com/docs/api/openapi/okta-management/management/tag/PrincipalRateLimit/" }, { title: "Profile Mappings", path: "https://developer.okta.com/docs/api/openapi/okta-management/management/tag/ProfileMapping/" }, { title: "Push Providers", path: "https://developer.okta.com/docs/api/openapi/okta-management/management/tag/PushProvider/" }, From 0486fd0e433dd7e5ca0eac5bd86cfe03803f20fc Mon Sep 17 00:00:00 2001 From: Thomas Cavanagh Date: Fri, 27 Sep 2024 15:36:49 -0400 Subject: [PATCH 4/8] Fixing links, formatting, acro scores --- .../docs/concepts/identity-providers/index.md | 38 ++++++------ .../main/index.md | 58 +++++++++---------- .../build-custom-ui-mobile/main/index.md | 16 ++--- .../main/index.md | 12 ++-- .../main/ios/enablesso.md | 2 +- .../index.md | 2 +- 6 files changed, 64 insertions(+), 64 deletions(-) diff --git a/packages/@okta/vuepress-site/docs/concepts/identity-providers/index.md b/packages/@okta/vuepress-site/docs/concepts/identity-providers/index.md index a8e056f3d05..c7c68f63f14 100644 --- a/packages/@okta/vuepress-site/docs/concepts/identity-providers/index.md +++ b/packages/@okta/vuepress-site/docs/concepts/identity-providers/index.md @@ -4,9 +4,9 @@ title: External Identity Providers # External Identity Providers -As a developer building a custom application, you want to give users the freedom to choose which Identity Provider they use to sign in to your application. But first you should understand how Identity Providers connect to Okta. +As a developer building a custom app, you want to give users the freedom to choose which Identity Provider they use to sign in to your app. But first you should understand how Identity Providers connect to Okta. -What is an Identity Provider? It's a service that creates and maintains identity information and then provides authentication services to your applications. Identity Providers can significantly reduce sign-in and registration friction. This allows your users to easily access applications without needing to create passwords or remember usernames. +What is an Identity Provider? It's a service that creates and maintains identity information and then provides authentication services to your apps. Identity Providers can significantly reduce sign-in and registration friction. This allows your users to easily access apps without needing to create passwords or remember usernames. Add an Identity Provider integration @@ -14,27 +14,27 @@ What is an Identity Provider? It's a service that creates and maintains identity ## The big picture -Okta manages connections to other Identity Providers for your application and sits between your application and the Identity Provider that authenticates your users. +Okta manages connections to other Identity Providers for your app and sits between your app and the Identity Provider that authenticates your users. -* You can use Okta as the [user store](/docs/concepts/user-profiles/) for your applications. Then, users can sign in with their email and password by default. See our guides for how to sign in users to your [web](/docs/guides/sign-into-web-app-redirect/), [mobile](/docs/guides/sign-into-mobile-app-redirect/), and [single-page](/docs/guides/sign-into-spa-redirect/) apps. +* You can use Okta as the [user store](/docs/concepts/user-profiles/) for your apps. Then, users can sign in with their email and password by default. See our guides for how to sign in users to your [web](/docs/guides/sign-into-web-app-redirect/), [mobile](/docs/guides/sign-into-mobile-app-redirect/), and [single-page](/docs/guides/sign-into-spa-redirect/) apps. -* You can add connections to social Identity Providers like Apple or Facebook. This is called social login or social authentication. It allows your users to sign in to your app using credentials from their existing social Identity Providers. After users authenticate, you sync their existing Identity Provider credentials into your Okta Universal Directory while continuing to use that Identity Provider for user authentication. This eliminates the need to store an additional username and password for that user. +* You can add connections to social Identity Providers like Apple or Facebook. This is called social login or social login. It allows your users to sign in to your app using credentials from their existing social Identity Providers. After users authenticate, you sync their existing Identity Provider credentials into your Okta Universal Directory while continuing to use that Identity Provider for user authentication. This eliminates the need to store an additional username and password for that user. -* You can add connections to Identity Providers that you build in-house that support OpenID Connect or SAML protocols. This is also referred to as Inbound Federation or inbound SAML. The SAML flow is initiated with the Service Provider (in this case, Okta) that redirects the user to the Identity Provider for authentication. After authentication, a user is created inside Okta, and the user is redirected back to your application along with an ID token. This allows you to use Okta to proxy between SAML-only Identity Providers and OpenID Connect-only applications that are normally incompatible. +* You can add connections to Identity Providers that you build in-house that support OpenID Connect or SAML protocols. This is also referred to as Inbound Federation or inbound SAML. The SAML flow is initiated with the Service Provider (in this case, Okta) that redirects the user to the Identity Provider for authentication. After authentication, a user is created inside Okta, and the user is redirected back to your app along with an ID token. This allows you to use Okta to proxy between SAML-only Identity Providers and OpenID Connect-only apps that are normally incompatible. > **Note:** Social and OpenID Connect Identity Providers store access tokens that allow subsequent calls to Identity Providers after the user is authorized. For example, the token may contain the permission to add events to a user's Google calendar. After authentication, your app can use the token on more calls to add events to the user's Google calendar on the user's behalf. * You can also configure federation [between Okta orgs](/docs/guides/add-an-external-idp/oktatookta/main/) using OpenID Connect or SAML. -Adding any of these Identity Providers allows users to sign in to your application using their credentials from a specific Identity Provider. +Adding any of these Identity Providers allows users to sign in to your app using their credentials from a specific Identity Provider. ## Benefits of using Okta to manage Identity Providers -You could connect your application directly to an Identity Provider (for example, using an SDK to add a button for **Sign in with Google**). However, using Okta as the user store for your application and letting Okta manage the Identity Provider connections has some benefits: +You could connect your app directly to an Identity Provider (for example, using an SDK to add a button for **Sign in with Google**). However, using Okta as the user store for your app and letting Okta manage the Identity Provider connections has some benefits: -* **No custom code:** Your application only needs to talk to Okta, and Okta does the rest. +* **No custom code:** Your app only needs to talk to Okta, and Okta does the rest. -* **One protocol:** Your application uses OpenID Connect to talk to Okta. Okta handles whatever protocols the other Identity Providers use, and this is transparent to your application. +* **One protocol:** Your app uses OpenID Connect to talk to Okta. Okta handles whatever protocols the other Identity Providers use, and this is transparent to your app. * **Single user store:** All users are stored in Okta. You can capture the profile attributes from an Identity Provider user and store those attributes in the Okta Universal Directory. @@ -48,19 +48,19 @@ You could connect your application directly to an Identity Provider (for example ## How Okta connects to external Identity Providers -Okta sits between your application and the external provider. Your application only needs to talk to Okta, and Okta does the rest. +Okta sits between your app and the external provider. Your app only needs to talk to Okta, and Okta does the rest. ### Sign-in process The sign-in process starts at the `/authorize` endpoint, and then goes out to the provider and back: -1. In your application, the user clicks a button similar to: **Sign in with (Identity Provider)**. -2. Your application redirects the browser to Okta. +1. In your app, the user clicks a button similar to: **Sign in with (Identity Provider)**. +2. Your app redirects the browser to Okta. 3. Okta redirects the browser to the Identity Provider. 4. The user is prompted to sign in at the Identity Provider (if they aren't already) and to accept the permissions required by your app. 5. The Identity Provider redirects the browser back to Okta. 6. Okta processes the sign-in request and adds the user to your Okta organization's Universal Directory. -7. Okta redirects the browser back to your application, just like any other sign-in request. +7. Okta redirects the browser back to your app, just like any other sign-in request.
@@ -91,7 +91,7 @@ ok -> ua: 302 to redirect_uri ## Account Linking and Just-In-Time provisioning -Use account linking to help create a unified view of your users within your org. Also, you can use Just-In-Time (JIT) provisioning to create a seamless experience for users that sign in to your application for the first time using their credentials from another Identity Provider. +Use account linking to help create a unified view of your users within your org. You can also use Just-In-Time (JIT) provisioning to create a seamless experience for users. User can sign in to your app for the first time using their credentials from another Identity Provider. ### Account Linking @@ -109,9 +109,9 @@ To enable account linking, select `Automatic` from the **Account Link Policy** d ### JIT provisioning -If a user signs in to your application for the first time using another Identity Provider, you can implement [JIT provisioning](https://help.okta.com/okta_help.htm?id=ext_Identity_Providers) to create an Okta account automatically for them. JIT account creation and activation only work for end users who aren't already Okta users. +If a user signs in to your app for the first time using another Identity Provider, you can implement [JIT provisioning](https://help.okta.com/okta_help.htm?id=ext_Identity_Providers) to create an Okta account automatically for them. JIT account creation and activation only work for end users who aren't already Okta users. -Also, you can apply granular control over account linking and JIT by defining a policy and then rules for the policy. You can base a policy on various factors, such as location, group definitions, and authentication type. A specific policy rule can then be created for groups that have been assigned to your application. You can create multiple policies with more or less restrictive rules and apply them to different groups. +Also, you can apply granular control over account linking and JIT by defining a policy and then rules for the policy. You can base a policy on various factors, such as location, group definitions, and authentication type. A specific policy rule can then be created for groups that have been assigned to your app. You can create multiple policies with more or less restrictive rules and apply them to different groups. You can also set up group sync to specify the groups that users should be added to and enable profile sourcing so that a user's profile gets updated each time that the user signs in. This allows you to always have the most recent data about your users. @@ -121,9 +121,9 @@ If you have more than one Identity Provider configured in your org (which can me The Okta Sign-In Widget (version 2.5.0 or above) interacts with the IdP Discovery policy to redirect end users as needed to the IdP determined by the policy. -> **Note:** v1 of the Okta API supports IdP Discovery with the Okta-hosted Widget only. +> **Note:** v1 of the Okta API supports IdP Discovery with the Okta-hosted Sign-In Widget only. -If you don't use the Okta Sign-In Widget, instead interacting directly with the [Okta Authentication API](/docs/reference/api/authn/) to implement sign-in yourself, you can integrate IdP Discovery into your flow by including a call to the Okta [WebFinger](/docs/reference/api/webfinger/) endpoint. That endpoint returns the name of the IdP that should be used for a given end user, as determined by the org's defined IdP Discovery Policy. +If you don't use the Okta Sign-In Widget, instead interacting directly with the [Okta Authentication API](/docs/reference/api/authn/) to implement sign-in yourself, you can integrate IdP Discovery into your flow by including a call to the Okta [WebFinger](/docs/reference/api/webfinger/) endpoint. That endpoint returns the name of the IdP that should be used for a given end user, as determined by the org's defined IdP discovery policy. Add an Identity Provider integration diff --git a/packages/@okta/vuepress-site/docs/guides/archive-configure-signon-policy/main/index.md b/packages/@okta/vuepress-site/docs/guides/archive-configure-signon-policy/main/index.md index 33b3a064201..d939fb2f9cb 100644 --- a/packages/@okta/vuepress-site/docs/guides/archive-configure-signon-policy/main/index.md +++ b/packages/@okta/vuepress-site/docs/guides/archive-configure-signon-policy/main/index.md @@ -4,9 +4,9 @@ excerpt: How to configure an Okta Sign-On policy and an app sign-on policy. layout: Guides --- -> **Note:** This document is only for Okta Classic Engine. If you are using Okta Identity Engine, see [Configure a global session policy and authentication policies](/docs/guides/configure-signon-policy). See [Identify your Okta solution](https://help.okta.com/okta_help.htm?type=oie&id=ext-oie-version) to determine your Okta version.” +> **Note:** This document is only for Okta Classic Engine. If you’re using Identity Engine, see [Configure a global session policy and authentication policies](/docs/guides/configure-signon-policy). See [Identify your Okta solution](https://help.okta.com/okta_help.htm?type=oie&id=ext-oie-version) to determine your Okta version.” -This guide explains how to add and configure Okta sign-on policies and app sign-on policies to your [Okta organization](/docs/concepts/okta-organizations/), and what the Policies are used for. +This guide explains what policies are, and how to add and configure Okta sign-on policies and app sign-on policies to your [Okta organization](/docs/concepts/okta-organizations/). --- @@ -19,20 +19,20 @@ This guide explains how to add and configure Okta sign-on policies and app sign- * [Okta Developer Edition organization](https://developer.okta.com/signup) * [Groups created](https://help.okta.com/okta_help.htm?id=ext_Directory_Groups) in your org -* An application that you want to add a Sign-On Policy to +* An app that you want to add a sign-on policy to * A configured [dynamic network zone](https://help.okta.com/okta_help.htm?id=ext_Security_Network) --- ## About the Okta Sign-On and app sign-on policies -An Okta sign-on policy helps you control who can sign in and how a user is allowed to sign in to Okta, including whether they are challenged for MFA and how long they are allowed to remain signed in before re-authenticating. Additionally, you can configure app sign-on policies for each application for extra levels of authentication that you may want performed before an application can be accessed. +An Okta sign-on policy helps you control who can sign in and how a user is allowed to sign in to Okta. Sign-on policies control whether users are challenged for MFA and how long they’re allowed to remain signed in before reauthenticating. You can also configure app sign-on policies for each app for extra levels of authentication before an app can be accessed. -Add a rule to the Okta sign-on policy, for example, when you need to make sure that only users who are inside your [corporate network](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicyRule!path=0/conditions/network&t=request) can access your application, or you need to exclude certain roles in your organization from accessing it. Add a rule for an app sign-on policy, for example, to prompt groups that are assigned to your app to re-authenticate after 60 minutes. There is only one app sign-on policy, but you can add as many rules to it as you need. +Add a rule to the Okta sign-on policy. For example, add a rule that ensures that only users who are inside your [corporate network](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicyRule!path=0/conditions/network&t=request) can access your app. Or add a rule that excludes certain roles in your organization from accessing your app. Add a rule for an app sign-on policy, for example, to prompt groups that are assigned to your app to reauthenticate after 60 minutes. There’s only one app sign-on policy, but you can add as many rules to it as you need. -You can specify any number of Okta sign-on policies and the order in which they are executed. If a policy in the list doesn't apply to the user trying to sign in, the system moves to the next policy. There is one required organization-wide policy named **Default**. By definition, the Default policy applies to all users. +You can specify any number of Okta sign-on policies and the order in which they’re executed. If a policy in the list doesn't apply to the user trying to sign in, the system moves to the next policy. There’s one required organization-wide policy named **Default**. By definition, the default policy applies to all users. -In addition to the Default policy, which you can't delete, there may be another organization-wide policy named **Legacy** that is present only if you have already configured MFA. This policy reflects the MFA settings that were in place when you enabled your Sign-On Policy and ensures that no changes in MFA behavior occur unless you modify your policy. If required, you can delete it. +In addition to the default policy, which you can't delete, there may be another organization-wide policy named **Legacy**. That policy is present only if you have already configured MFA. This policy reflects the MFA settings that were in place when you enabled your sign-on policy. And it ensures that no changes in MFA behavior occur unless you modify your policy. If required, you can delete it. > **Note:** See [Policies](/docs/concepts/policies) for an overview of the supported Okta policies and how they work. @@ -45,7 +45,7 @@ This guide provides step-by-step instructions to configure an Okta sign-on polic ## Prompt for an MFA factor for a certain group -The following are step-by-step instructions to configure an Okta sign-on policy to prompt a user for a factor (multifactor authentication (MFA)) when the user is a member of a certain group. +The following are step-by-step instructions to configure an Okta sign-on policy. Use this policy to prompt a user for a factor (multifactor authentication (MFA)) when the user is a member of a certain group. ### Create the policy container @@ -55,25 +55,25 @@ The following are step-by-step instructions to configure an Okta sign-on policy 3. In the **Add Policy** window, enter a **Policy Name**, such as **Require MFA for Contractors**, and then enter a **Policy Description**. -4. In the **Assign to Groups** box, enter the group name that you want to apply the policy to. In this example, we are specifying the **Contractor** group in our org. The group names must already exist before assigning them to a policy. +4. In the **Assign to Groups** box, enter the group name that you want to apply the policy to. In this example, specify the **Contractor** group in your org. You must create the group before assigning it to the policy. 5. Click **Create Policy and Add Rule**. ### Create the rule -1. In the **Add Rule** window, add a descriptive name for the rule in the **Rule name** box, such as **Require contractors to use MFA once per session**. +1. In the **Add Rule** window, add a descriptive name for the rule in the **Rule name** box. For example, name it as **Require contractors to use MFA once per session**. 2. If there are any users in the **Contractor** group that you want to exclude from the rule, enter them in the **Exclude Users** box. -3. For this use case example, leave the default of **Anywhere** in the **If User's IP is** drop-down box. For other use cases where you want to assign location parameters, you can specify what kind of location prompts authentication, for example, prompting a user for a factor when they aren't on the corporate network. +3. For this use case example, leave the default of **Anywhere** in the **If User's IP is** dropdown box. For other use cases where you want to assign location parameters, you can specify what kind of location prompts authentication. For example, you can prompt a user for a factor when they aren't on the corporate network. - > **Note:** You can click the **Networks** link to access the gateway settings that enable your choice of access. A [network zone](https://help.okta.com/okta_help.htm?id=ext_Security_Network) is a security perimeter used to limit or restrict access to a network based on a single IP address, one or more IP address ranges, or a list of geolocations. You can also create networks zones using the [Zone API](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/NetworkZone/). + > **Note:** You can click the **Networks** link to access the gateway settings that enable your choice of access. A [network zone](https://help.okta.com/okta_help.htm?id=ext_Security_Network) is a security perimeter used to limit or restrict access to a network based on a single IP address, one or more IP address ranges, or a list of geolocations. You can also create network zones using the [Zone API](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/NetworkZone/). -4. Leave the default of **Any** in the **And Authenticates via** drop-down box. +4. Leave the default of **Any** in the **And Authenticates via** dropdown box. -5. Select **Allowed** from the **Then Access is** drop-down box to allow access based on the conditions defined. +5. Select **Allowed** from the **Then Access is** dropdown box to allow access based on the conditions defined. -6. Leave the **Prompt for Factor** check box selected so that users of the **Contractor** group are prompted for a factor before they are granted access. This check box appears only when at least one factor type is enabled in your org. +6. Leave the **Prompt for Factor** checkbox selected so that users of the **Contractor** group are prompted for a factor before they’re granted access. This checkbox appears only when at least one factor type is enabled in your org. > **Note:** Click the **Multifactor Authentication** link for quick access to the **Authentication** page and the **Multifactor** tab to define the factors that you want to use. @@ -82,24 +82,24 @@ The following are step-by-step instructions to configure an Okta sign-on policy You can configure whether the factor prompt is triggered per a device, at every sign-on, or per a session time that you specify: * **Per Device:** Provides the option **Do not challenge me on this device again** on the end user MFA challenge dialog box. This option allows prompts solely for new devices. - * **Every Time:** End users are prompted every time they sign in to Okta and can't influence when they are prompted to provide a factor. - * **Per Session:** Provides the option **Do not challenge me on this device for the next (minutes/hours/days)** on the end user MFA challenge dialog box. You specify the **Factor Lifetime** below. When specifying per session, note that sessions have a default lifetime as configured, but sessions always end whenever users sign out of their Okta session. + * **Every Time:** End users are prompted every time they sign in to Okta and can't influence when they’re prompted to provide a factor. + * **Per Session:** Provides the option **Do not challenge me on this device for the next (minutes/hours/days)** on the end user MFA challenge dialog box. You can then specify the **Factor Lifetime**. When specifying per session sessions have a default lifetime as configured, but sessions always end whenever users sign out of their Okta session. 8. For this use case example, leave the default **Factor Lifetime** of **15 minutes**. Use these fields to specify how much time must elapse before the user is challenged for MFA. - The maximum lifetime period is six months. Setting a factor lifetime is a way for end users to sign out for the amount of time noted in the **Factor Lifetime** and not have to authenticate again with MFA at the next sign in. End users must select a box when they sign in to confirm that the setting should be applied. An example is **Do not challenge me on this device for the next 15 minutes**. In this case, after signing out, there is no MFA prompt if the user signs in again within 15 minutes of the last sign in with MFA. If users don't select the box, they are always prompted for MFA. The time since the last sign in is noted at the bottom of the End-User Dashboard. However, end users must refresh the page to see the updated value. + The maximum lifetime period is six months. Setting a factor lifetime is a way for end users to sign out for the amount of time noted in the **Factor Lifetime**. They don't have to authenticate again with MFA at the next sign in. End users must select a box when they sign in to confirm that the setting should be applied. An example is **Do not challenge me on this device for the next 15 minutes**. After signing out, there’s no MFA prompt if the user signs in again within 15 minutes of the last sign in with MFA. If users don't select the box, they’re always prompted for MFA. The time since the last sign-in is noted at the bottom of the End-User Dashboard. However, end users must refresh the page to see the updated value. 9. For this use case example, leave the default **Session Expires After** setting of **2 hours**. Use these fields to specify the maximum idle time before an authentication prompt is triggered. The maximum allowed time for this option is 90 days. This isn't the total connect time. This is idle time before users see a countdown timer at the 5-minute mark of remaining session time. - > **Note:** You can set the [maximum session lifetime value](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicyRule!path=4/actions/signon/session&t=request) using the Okta APIs. If you previously set this value using the API, you can't exceed that maximum in the UI. Setting a value over the API maximum results in an error. + > **Note:** You can set the [maximum session lifetime value](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicyRule!path=4/actions/signon/session/maxSessionLifetimeMinutes&t=request) using the Okta APIs. If you previously set this value using the API, you can't exceed that maximum in the UI. Setting a value over the API maximum results in an error. 10. Click **Create Rule**. -> **Note:** After you create a new policy, you must close all active sessions for the new policy to take effect. +> **Note:** After you create a policy, you must close all active sessions for the new policy to take effect. -## Prompt for an MFA factor when a user is outside the US +## Prompt for MFA factor when a user is outside the US -In addition to the Okta sign-on policy, there is an app sign-on policy for each application that determines the extra levels of authentication that you may want performed before a user can access an application. The following are step-by-step instructions to configure an app sign-on policy to prompt a user for an MFA factor when the user is outside the United States. +In addition to the Okta sign-on policy, there’s an app sign-on policy for each app. The app sign-on policy determines the extra levels of authentication that can be performed before a user accesses an app. The following are instructions to configure an app sign-on policy to prompt a user for an MFA factor when they're outside the United States. > **Note:** This example assumes that you have already [set up a Dynamic Zone](https://help.okta.com/okta_help.htm?id=ext_Security_Network) for the United States. @@ -107,7 +107,7 @@ In addition to the Okta sign-on policy, there is an app sign-on policy for each 1. In the Admin Console, select **Applications** > **Applications**. -2. Select the app that you want to configure a Sign-On Policy for. In this example, we are using a Web App. +2. Select the app that you want to configure a sign-on policy for. In this example, use a Web App. 3. Click **Sign On** and scroll down to the **Sign On Policy** section. @@ -121,25 +121,25 @@ In addition to the Okta sign-on policy, there is an app sign-on policy for each 3. Select who the rule applies to in the **People** section. In this use case example, select **The following groups and users:**. -4. In the **Groups** box that appears, enter the group that you want this rule to apply to. In this example, we are using **Everyone**. You can also add specific users that you want to include in the **Users** box. +4. In the **Groups** box that appears, enter the group that you want this rule to apply to. In this example, use **Everyone**. You can also add specific users that you want to include in the **Users** box. If you want to exclude specific groups and users from the policy rule, select **Exclude the following users and groups from this rule:** and then specify the groups and users. 5. Specify the location to which you want the policy to apply in the **LOCATION** section of the dialog box. In this example, select **In Zone**. -6. In the **Network Zones** box that appears, enter the name of the zone that you want to apply, and then add it when it appears in the list. In this example, we are adding the [network zone](https://help.okta.com/okta_help.htm?id=ext_Security_Network) for the United States that we suggested you create at the start of the guide. +6. In the **Network Zones** box that appears, enter the name of the zone that you want to apply. Then add it when it appears in the list. In this example, add a [network zone](https://help.okta.com/okta_help.htm?id=ext_Security_Network) for the United States. Create a network zone for the United States if you haven't already. 7. In the **CLIENT** section, clear the platform conditions that you don't want the rule to apply to. In this example, leave the default of all platforms selected. -8. For this use case, in the **ACTIONS** section, leave the default of **Allowed** for the **When all the conditions above are met, sign on to this application is** drop-down box. +8. For this use case, in the **ACTIONS** section, leave the default of **Allowed** for the **When all the conditions above are met, sign on to this application is** dropdown box. -9. Select the **Prompt for factor** check box to require users who are outside of the United States to choose an MFA option for additional authentication. +9. Select the **Prompt for factor** checkbox to require users who are outside of the United States to choose an MFA option for extra authentication. > **Note:** The **Multifactor Settings** link takes you to the Multifactor Authentication page, where you can add factors. 10. Then, specify how frequently you want the users to be prompted. Select **Once per session** for this use case. - > **Note:** While you can configure your App sign-on policies to prompt end users for MFA, be aware that legacy protocols such as `POP` or `IMAP` don't support MFA even if MFA is configured. + > **Note:** While you can configure your app sign-on policies to prompt end users for MFA, legacy protocols such as `POP` or `IMAP` don't support MFA even if MFA is configured. 11. Click **Save**. @@ -147,7 +147,7 @@ In addition to the Okta sign-on policy, there is an app sign-on policy for each You should now understand how to add an Okta sign-on policy and an app sign-on policy. -Next, take a look at the following: +Next, go to the following pages: * [Sign Users Out](/docs/guides/sign-users-out/) * [Set up self-registration](/docs/guides/archive-set-up-self-service-registration/) diff --git a/packages/@okta/vuepress-site/docs/guides/build-custom-ui-mobile/main/index.md b/packages/@okta/vuepress-site/docs/guides/build-custom-ui-mobile/main/index.md index d4c255797bb..fc84a4697eb 100644 --- a/packages/@okta/vuepress-site/docs/guides/build-custom-ui-mobile/main/index.md +++ b/packages/@okta/vuepress-site/docs/guides/build-custom-ui-mobile/main/index.md @@ -6,13 +6,13 @@ layout: Guides -You can connect your mobile app to Okta and sign users in by [opening a browser](/docs/guides/sign-into-mobile-app-redirect/). However, if you prefer that users not leave your app, build a custom sign-in UI with native controls and screens instead. +You can connect your mobile app to Okta and sign users in by [opening a browser](/docs/guides/sign-into-mobile-app-redirect/). However, if you prefer that users not leave your app, build a custom sign-in UI with platform-specific controls and screens instead. -Use this guide to build a customized sign-in experience inside your mobile application. +Use this guide to build a customized sign-in experience inside your mobile app. -> **Note:** If the browser sign-in method works for your application, Okta recommends using that because building a custom sign-in UI takes more effort and development time. +> **Note:** If the browser sign-in method works for your app, Okta recommends using that because building a custom sign-in UI takes more effort and development time. --- @@ -31,19 +31,19 @@ Customize the sign-in experience with a mobile sign-in UI. --- -## Create an Okta application +## Create an Okta app -Before you can sign a user in, you need to create an Okta application that represents your mobile application. +Before you can sign a user in, you need to create an Okta app that represents your mobile app. -Use the Okta application that you created when you walked through the [Sign users into your mobile app using the redirect model](/docs/guides/sign-into-mobile-app/-/main/#create-an-okta-integration-for-your-app) guide. +Use the Okta app that you created when you walked through the [Sign users into your mobile app using the redirect model](/docs/guides/sign-into-mobile-app/-/main/#create-an-okta-integration-for-your-app) guide. ## Add and configure packages -To build the custom sign-in UI, you need to install and configure a native Okta SDK to your application. +To build the custom sign-in UI, you need to install and configure a platform-specific Okta SDK to your app. You should already have added and configured packages when you walked through the [Sign users into your mobile app using the redirect model](/docs/guides/sign-into-mobile-app/-/main/#add-packages) guide. -In addition, you need to install the native Okta Authentication SDK. This SDK works together with the OpenID Connect SDK that you have already installed to make authentication requests to Okta. +In addition, you need to install the platform-specific Okta Authentication SDK. This SDK works together with the OpenID Connect SDK that you have already installed to make authentication requests to Okta. diff --git a/packages/@okta/vuepress-site/docs/guides/oie-upgrade-mfa-enroll-policy/main/index.md b/packages/@okta/vuepress-site/docs/guides/oie-upgrade-mfa-enroll-policy/main/index.md index b2ae208a432..b070114862a 100644 --- a/packages/@okta/vuepress-site/docs/guides/oie-upgrade-mfa-enroll-policy/main/index.md +++ b/packages/@okta/vuepress-site/docs/guides/oie-upgrade-mfa-enroll-policy/main/index.md @@ -57,9 +57,9 @@ To parse a response from the `GET /api/v1/policies?type=MFA_ENROLL` request, you > **Note:** Another indicator of an authenticator-based enrollment policy is when `type=AUTHENTICATORS` in the [settings schema](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy!path=2/settings&t=request). The `type` property could be absent from the response of factor-based authenticator enrollment policies. -If the returned policy uses `authenticators`, loop through the list of [Policy Authenticator objects](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy!path=2/settings/authenticators/key&t=request) and use the `key` property to identify the authenticator. See the [Authenticators API](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Authenticator/) for more details on the available authenticators in your org. +If the returned policy uses `authenticators`, loop through the list of [policy authenticator objects](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy!path=2/settings/authenticators&t=request) and use the `key` property to identify the authenticator. See the [Authenticators API](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Authenticator/) for more details on the available authenticators in your org. -If the returned policy uses `factors`, you need to loop through every type of [Policy Factor Configuration object](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy!path=2/settings/type&t=request), as you've done previously for your app. +If the returned policy uses `factors`, you need to loop through every type of [policy factor configuration object](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy!path=2/settings/authenticators/key&t=request), as you've done previously for your app. Response example of an authenticator enrollment policy `settings` snippet with authenticators: @@ -110,17 +110,17 @@ Response example of an authenticator enrollment policy `settings` snippet with f ## Create an authenticator enrollment policy -To create an authenticator enrollment policy through the [Policy API](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy), you need to provide the `settings` schema with either the list of [Policy Authenticator objects](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy!path=2/settings/authenticators/constraints&t=request) or [Policy Factors Configuration objects](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy!path=2/settings&t=request) in the `POST /api/v1/policies` request body parameters. +To create an authenticator enrollment policy through the [Policy API](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy), you need to provide the `settings` schema with either the list of [policy authenticator objects](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy!path=2/settings/authenticators&t=request) or [policy factor configuration objects](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy!path=2/settings/authenticators/key&t=request) in the `POST /api/v1/policies` request body parameters. To create an authenticator enrollment policy in Identity Engine, use the [Policies API](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy). To set the list of authenticators for the policy, use the [Authenticators API](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Authenticator/#tag/Authenticator/operation/listAuthenticators). -You can also create an authenticator enrollment policy with factors instead of authenticators to support legacy systems or workflows. Set the policy `settings` to the factors schema with the [Policy Factors Configuration object](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy!path=2/settings/authenticators/constraints&t=request). +You can also create an authenticator enrollment policy with factors instead of authenticators to support legacy systems or workflows. Set the policy `settings` to the factors schema with the [policy factor configuration objects](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy!path=2/settings/authenticators/key&t=request). > **Note:** Configure the other policy parameters according to the [Create a Policy](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy) API operation. Specifically, you need to include the `type=MFA_ENROLL` parameter for an authenticator enrollment policy. ## Update an authenticator enrollment policy -To update an authenticator enrollment policy through the [Update a Policy](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/replacePolicy) API operation, you need to provide the `settings` schema with either the list of [Policy Authenticator objects](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/replacePolicy) or [Policy Factors Configuration objects](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/replacePolicy) in the `PUT /api/v1/policies/{policyId}` request body parameters. +To update an authenticator enrollment policy through the [Update a Policy](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/replacePolicy) API operation, you need to provide the `settings` schema with either the list of [policy authenticator objects](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy!path=2/settings/authenticators&t=request) or [policy factor configuration objects](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy!path=2/settings/authenticators/key&t=request) in the `PUT /api/v1/policies/{policyId}` request body parameters. > **Note:** Configure the other policy parameters according to the [Update a Policy](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/replacePolicy) API operation. This section focuses on the `settings` parameter required specifically for the authenticator enrollment policy. @@ -128,7 +128,7 @@ If you need to convert an existing factor-based authenticator enrollment policy You can revert to the factor-based authenticator enrollment policy model. Modify an existing authenticator-based enrollment policy to a factored one. To convert the authenticator keys to Policy Factor Configuration objects, see the following: -* [Policy Factors Configuration objects](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy!path=2/settings&t=request) +* [Policy factor configuration objects](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy!path=2/settings/authenticators/key&t=request) * [Policy Factors Configuration object and Authenticator keys mapping](#policy-factors-configuration-object-and-authenticator-keys-mapping) > **Note:** Your app might be integrated with systems like Terraform that you can't update to parse the authenticators-based enrollment policy. If so, revert your policy to use factors instead of authenticators. diff --git a/packages/@okta/vuepress-site/docs/guides/shared-sso-android-ios/main/ios/enablesso.md b/packages/@okta/vuepress-site/docs/guides/shared-sso-android-ios/main/ios/enablesso.md index bb06c1f8e73..6f12915b0c7 100644 --- a/packages/@okta/vuepress-site/docs/guides/shared-sso-android-ios/main/ios/enablesso.md +++ b/packages/@okta/vuepress-site/docs/guides/shared-sso-android-ios/main/ios/enablesso.md @@ -1,4 +1,4 @@ -To enable persistent SSO for iOS apps, you need to update the [`usePersistentCookie`](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicyRule!path=4/actions/signon/session/usePersistentCookie&t=request) parameter in the appropriate global session policy. These steps use the Okta [Policy Postman collection](/docs/reference/postman-collections/) to enable the parameter. +To enable persistent SSO for iOS apps, you need to update the [`usePersistentCookie`](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicyRule!path=4/actions/signon/session/usePersistentCookie&t=request) parameter in the appropriate global session policy. These steps use the Okta [Policy Postman collection](https://www.postman.com/okta-eng/workspace/okta-public-api-collections/overview) to enable the parameter. Before you begin, be sure to: diff --git a/packages/@okta/vuepress-site/docs/reference/okta-expression-language-in-identity-engine/index.md b/packages/@okta/vuepress-site/docs/reference/okta-expression-language-in-identity-engine/index.md index 9d2c01b8ed0..5e367aac18a 100644 --- a/packages/@okta/vuepress-site/docs/reference/okta-expression-language-in-identity-engine/index.md +++ b/packages/@okta/vuepress-site/docs/reference/okta-expression-language-in-identity-engine/index.md @@ -88,7 +88,7 @@ You can specify certain [Expression Language conditions](https://developer.okta. | ------ | ----------- | ---- | | `accessRequest.$operation`| `accessRequest` references the access context of the request. `operation` references the account management operation: `enroll`, `unenroll`, `recover`, or `unlockAccount`. | String | | `accessRequest.authenticator.$id` | `accessRequest` references the access context of the request. `authenticator.id` references an optional authenticator `id`, for example, the `id` of a custom authenticator. | String | -| `accessRequest.authenticator.$key` | `accessRequest` references the access context of the request. `authenticator.key` references the [authenticator key](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicyRule!path=0/actions/appSignOn/verificationMethod/0/constraints&t=request). | String | +| `accessRequest.authenticator.$key` | `accessRequest` references the access context of the request. `authenticator.key` references the [authenticator key](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicyRule!path=0/actions/appSignOn/verificationMethod/0/constraints/knowledge/authenticationMethods/key&t=request). | String | ## Functions From 2481fd829a88f1e01401774fc76c6d1f61319adb Mon Sep 17 00:00:00 2001 From: thomascavanagh-okta Date: Fri, 27 Sep 2024 16:57:51 -0400 Subject: [PATCH 5/8] Apply suggestions from code review Co-authored-by: barbaravo-okta <87335401+barbaravo-okta@users.noreply.github.com> --- .../docs/concepts/identity-providers/index.md | 28 +++++++++---------- .../docs/release-notes/2023/index.md | 2 +- 2 files changed, 15 insertions(+), 15 deletions(-) diff --git a/packages/@okta/vuepress-site/docs/concepts/identity-providers/index.md b/packages/@okta/vuepress-site/docs/concepts/identity-providers/index.md index c7c68f63f14..ea301375c95 100644 --- a/packages/@okta/vuepress-site/docs/concepts/identity-providers/index.md +++ b/packages/@okta/vuepress-site/docs/concepts/identity-providers/index.md @@ -4,9 +4,9 @@ title: External Identity Providers # External Identity Providers -As a developer building a custom app, you want to give users the freedom to choose which Identity Provider they use to sign in to your app. But first you should understand how Identity Providers connect to Okta. +As a developer building a custom app, you want to give users the freedom to choose which Identity Provider (IdP) they use to sign in to your app. But first you should understand how IdPs connect to Okta. -What is an Identity Provider? It's a service that creates and maintains identity information and then provides authentication services to your apps. Identity Providers can significantly reduce sign-in and registration friction. This allows your users to easily access apps without needing to create passwords or remember usernames. +What's an IdP? It's a service that creates and maintains identity information and then provides authentication services to your apps. IdPs can significantly reduce sign-in and registration friction. This allows your users to easily access apps without needing to create passwords or remember usernames. Add an Identity Provider integration @@ -14,29 +14,29 @@ What is an Identity Provider? It's a service that creates and maintains identity ## The big picture -Okta manages connections to other Identity Providers for your app and sits between your app and the Identity Provider that authenticates your users. +Okta manages connections to other IdPs for your app and sits between your app and the IdP that authenticates your users. * You can use Okta as the [user store](/docs/concepts/user-profiles/) for your apps. Then, users can sign in with their email and password by default. See our guides for how to sign in users to your [web](/docs/guides/sign-into-web-app-redirect/), [mobile](/docs/guides/sign-into-mobile-app-redirect/), and [single-page](/docs/guides/sign-into-spa-redirect/) apps. -* You can add connections to social Identity Providers like Apple or Facebook. This is called social login or social login. It allows your users to sign in to your app using credentials from their existing social Identity Providers. After users authenticate, you sync their existing Identity Provider credentials into your Okta Universal Directory while continuing to use that Identity Provider for user authentication. This eliminates the need to store an additional username and password for that user. +* You can add connections to social IdPs like Apple or Facebook. This is called social login or social login. It allows your users to sign in to your app using credentials from their existing social IdPs. After users authenticate, you sync their existing IdP credentials into your Okta Universal Directory while continuing to use that IdP for user authentication. This eliminates the need to store an additional username and password for that user. -* You can add connections to Identity Providers that you build in-house that support OpenID Connect or SAML protocols. This is also referred to as Inbound Federation or inbound SAML. The SAML flow is initiated with the Service Provider (in this case, Okta) that redirects the user to the Identity Provider for authentication. After authentication, a user is created inside Okta, and the user is redirected back to your app along with an ID token. This allows you to use Okta to proxy between SAML-only Identity Providers and OpenID Connect-only apps that are normally incompatible. +* You can add connections to IdPs that you build in-house that support OpenID Connect (OIDC) or SAML protocols. This is also referred to as Inbound Federation or inbound SAML. The SAML flow is initiated with the Service Provider (SP) (in this case, Okta) that redirects the user to the IdP for authentication. After authentication, a user is created inside Okta, and the user is redirected back to your app along with an ID token. This allows you to use Okta to proxy between SAML-only IdPs and OIDC-only apps that are normally incompatible. - > **Note:** Social and OpenID Connect Identity Providers store access tokens that allow subsequent calls to Identity Providers after the user is authorized. For example, the token may contain the permission to add events to a user's Google calendar. After authentication, your app can use the token on more calls to add events to the user's Google calendar on the user's behalf. + > **Note:** Social and OIDC IdPs store access tokens that allow subsequent calls to IdPs after the user is authorized. For example, the token may contain the permission to add events to a user's Google calendar. After authentication, your app can use the token on more calls to add events to the user's Google calendar on the user's behalf. -* You can also configure federation [between Okta orgs](/docs/guides/add-an-external-idp/oktatookta/main/) using OpenID Connect or SAML. +* You can also configure federation [between Okta orgs](/docs/guides/add-an-external-idp/oktatookta/main/) using OIDC or SAML. -Adding any of these Identity Providers allows users to sign in to your app using their credentials from a specific Identity Provider. +Adding any of these IdPs allows users to sign in to your app using their credentials from a specific IdP. ## Benefits of using Okta to manage Identity Providers -You could connect your app directly to an Identity Provider (for example, using an SDK to add a button for **Sign in with Google**). However, using Okta as the user store for your app and letting Okta manage the Identity Provider connections has some benefits: +You could connect your app directly to an IdP (for example, using an SDK to add a button for **Sign in with Google**). However, using Okta as the user store for your app and letting Okta manage the IdP connections has some benefits: * **No custom code:** Your app only needs to talk to Okta, and Okta does the rest. -* **One protocol:** Your app uses OpenID Connect to talk to Okta. Okta handles whatever protocols the other Identity Providers use, and this is transparent to your app. +* **One protocol:** Your app uses OIDC to talk to Okta. Okta handles whatever protocols the other IdPs use, and this is transparent to your app. -* **Single user store:** All users are stored in Okta. You can capture the profile attributes from an Identity Provider user and store those attributes in the Okta Universal Directory. +* **Single user store:** All users are stored in Okta. You can capture the profile attributes from an IdP user and store those attributes in the Okta Universal Directory. * **Profile sync:** If a user updates their profile at the Identity Provider, those changes appear in Okta the next time they use the provider to sign in. @@ -56,8 +56,8 @@ The sign-in process starts at the `/authorize` endpoint, and then goes out to th 1. In your app, the user clicks a button similar to: **Sign in with (Identity Provider)**. 2. Your app redirects the browser to Okta. -3. Okta redirects the browser to the Identity Provider. -4. The user is prompted to sign in at the Identity Provider (if they aren't already) and to accept the permissions required by your app. +3. Okta redirects the browser to the IdP. +4. The user is prompted to sign in at the IdP (if they aren't already) and to accept the permissions that are required by your app. 5. The Identity Provider redirects the browser back to Okta. 6. Okta processes the sign-in request and adds the user to your Okta organization's Universal Directory. 7. Okta redirects the browser back to your app, just like any other sign-in request. @@ -91,7 +91,7 @@ ok -> ua: 302 to redirect_uri ## Account Linking and Just-In-Time provisioning -Use account linking to help create a unified view of your users within your org. You can also use Just-In-Time (JIT) provisioning to create a seamless experience for users. User can sign in to your app for the first time using their credentials from another Identity Provider. +Use account linking to help create a unified view of your users within your org. You can also use Just-In-Time (JIT) provisioning to create a seamless experience for users. User can sign in to your app for the first time using their credentials from another IdP. ### Account Linking diff --git a/packages/@okta/vuepress-site/docs/release-notes/2023/index.md b/packages/@okta/vuepress-site/docs/release-notes/2023/index.md index 80073bd992b..e7ebafbaded 100644 --- a/packages/@okta/vuepress-site/docs/release-notes/2023/index.md +++ b/packages/@okta/vuepress-site/docs/release-notes/2023/index.md @@ -228,7 +228,7 @@ Users now receive an authentication challenge for each redirect sent to an Ident #### Policy Simulation API is GA in Preview -With the Policy API `/simulate` endpoint, you can quickly and easily test policies and validate whether your desired security outcomes are achieved. This endpoint allows you to simulate user access attributes, such as IP address, device, risk, and so on, to test whether the user is granted access to the specified application. This endpoint is implemented in the Admin Console as the [Access Testing Tool](https://help.okta.com/oie/en-us/Content/Topics/identity-engine/policies/access-testing-tool.htm). The `/simulate` endpoint helps you identify potential security risks and compliance issues before you implement a policy. See the [Policy API](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicySimulation) and [Test your policies with access simulations](/docs/guides/policy-simulation). +With the Policy API `/simulate` endpoint, you can quickly and easily test policies and validate whether your desired security outcomes are achieved. This endpoint allows you to simulate user access attributes, such as IP address, device, risk, and so on, to test whether the user is granted access to the specified app. This endpoint is implemented in the Admin Console as the [Access Testing Tool](https://help.okta.com/oie/en-us/Content/Topics/identity-engine/policies/access-testing-tool.htm). The `/simulate` endpoint helps you identify potential security risks and compliance issues before you implement a policy. See the [Policy API](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicySimulation) and [Test your policies with access simulations](/docs/guides/policy-simulation). #### Developer documentation update in 2023.08.0 From ae044d18155de2aedd91cc6cf35f286bb4135561 Mon Sep 17 00:00:00 2001 From: thomascavanagh-okta Date: Fri, 27 Sep 2024 17:01:23 -0400 Subject: [PATCH 6/8] Apply suggestions from code review Co-authored-by: barbaravo-okta <87335401+barbaravo-okta@users.noreply.github.com> --- .../docs/guides/step-up-authentication/main/index.md | 2 +- .../docs/release-notes/2023-okta-identity-engine/index.md | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/packages/@okta/vuepress-site/docs/guides/step-up-authentication/main/index.md b/packages/@okta/vuepress-site/docs/guides/step-up-authentication/main/index.md index 6e0e73fdf72..28b18b226e9 100644 --- a/packages/@okta/vuepress-site/docs/guides/step-up-authentication/main/index.md +++ b/packages/@okta/vuepress-site/docs/guides/step-up-authentication/main/index.md @@ -27,7 +27,7 @@ Users want seamless access to certain resources, but organizations want to incre The `acr_values` parameter refers to authentication context class reference. Each value defines a specific set of assurance level requirements that the protected resource requires from the authentication event associated with the access and ID tokens. -Today an authorization server relies on [authentication policies](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicyRule) to authenticate the user. After the user is authenticated, the authorization server evaluates the scopes and the grant types defined for the app, and then issues the tokens. Although this approach works in many situations, there are several circumstances where more is needed. Resource servers (your protected APIs) can require different authentication strengths or elapsed time frames for different use cases. For example, an eCommerce app requires different authentication strengths depending on whether the item being purchased exceeds a certain threshold. Another example is an app that requires a higher level of assurance before making changes to sensitive information. +Today an authorization server relies on [authentication policies](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicyRule) to authenticate the user. After the user is authenticated, the authorization server evaluates the scopes and the grant types defined for the app, and then issues the tokens. Although this approach works in many situations, there are several circumstances where more is needed. Resource servers (your protected APIs) can require different authentication strengths or elapsed time frames for different use cases. For example, an ecommerce app requires different authentication strengths depending on whether the item being purchased exceeds a certain threshold. Another example is an app that requires a higher level of assurance before making changes to sensitive information. Okta has created predefined `acr_values` that are described in the [Predefined parameter values](#predefined-parameter-values) section. You can include one of these values, based on your use case, in the client authorization request to request a different authentication assurance. The authorization server returns an access token and/or an ID token that contains the `acr` claim. This claim conveys information about the level of assurance that the user verified at the time of authentication. The resource server can then validate these parameters to ensure that the user verified the required level of assurance. diff --git a/packages/@okta/vuepress-site/docs/release-notes/2023-okta-identity-engine/index.md b/packages/@okta/vuepress-site/docs/release-notes/2023-okta-identity-engine/index.md index 4977a53464b..8325162f775 100644 --- a/packages/@okta/vuepress-site/docs/release-notes/2023-okta-identity-engine/index.md +++ b/packages/@okta/vuepress-site/docs/release-notes/2023-okta-identity-engine/index.md @@ -250,7 +250,7 @@ Users now receive an authentication challenge for each redirect sent to an Ident Direct authentication out-of-band (OOB) and multifactor out-of-band (MFA OOB) grant flows now support number challenge for Okta Verify Push. See the [MFA OOB grant](/docs/guides/configure-direct-auth-grants/dmfaoobov/main/) and [OOB grant](/docs/guides/configure-direct-auth-grants/coobov/main/) flows. #### Policy Simulation API is GA in Preview -With the Policy API `/simulate` endpoint, you can quickly and easily test policies and validate whether your desired security outcomes are achieved. This endpoint allows you to simulate user access attributes, such as IP address, device, risk, and so on, to test whether the user is granted access to the specified application. This endpoint is implemented in the Admin Console as the [Access Testing Tool](https://help.okta.com/oie/en-us/Content/Topics/identity-engine/policies/access-testing-tool.htm). The `/simulate` endpoint helps you identify potential security risks and compliance issues before you implement a policy. See the [Policy API](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicySimulation) and [Test your policies with access simulations](/docs/guides/policy-simulation). +With the Policy API `/simulate` endpoint, you can quickly and easily test policies and validate whether your desired security outcomes are achieved. This endpoint allows you to simulate user access attributes, such as IP address, device, risk, and so on, to test whether the user is granted access to the specified app. This endpoint is implemented in the Admin Console as the [Access Testing Tool](https://help.okta.com/oie/en-us/Content/Topics/identity-engine/policies/access-testing-tool.htm). The `/simulate` endpoint helps you identify potential security risks and compliance issues before you implement a policy. See the [Policy API](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicySimulation) and [Test your policies with access simulations](/docs/guides/policy-simulation). #### Developer documentation update in 2023.09.0 @@ -331,7 +331,7 @@ Users now receive an authentication challenge for each redirect sent to an Ident #### Policy Simulation API is GA in Preview -With the Policy API `/simulate` endpoint, you can quickly and easily test policies and validate whether your desired security outcomes are achieved. This endpoint allows you to simulate user access attributes, such as IP address, device, risk, and so on, to test whether the user is granted access to the specified application. This endpoint is implemented in the Admin Console as the [Access Testing Tool](https://help.okta.com/oie/en-us/Content/Topics/identity-engine/policies/access-testing-tool.htm). The `/simulate` endpoint helps you identify potential security risks and compliance issues before you implement a policy. See the [Policy API](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicySimulation) and [Test your policies with access simulations](/docs/guides/policy-simulation). +With the Policy API `/simulate` endpoint, you can quickly and easily test policies and validate whether your desired security outcomes are achieved. This endpoint allows you to simulate user access attributes, such as IP address, device, risk, and so on, to test whether the user is granted access to the specified app. This endpoint is implemented in the Admin Console as the [Access Testing Tool](https://help.okta.com/oie/en-us/Content/Topics/identity-engine/policies/access-testing-tool.htm). The `/simulate` endpoint helps you identify potential security risks and compliance issues before you implement a policy. See the [Policy API](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicySimulation) and [Test your policies with access simulations](/docs/guides/policy-simulation). #### Developer documentation updates in 2023.08.0 @@ -483,7 +483,7 @@ The Policy API Self-Service Password Reset object can now use Google Authenticat #### Policy Simulation API is EA in Preview -With the Policy API `/simulate` endpoint, you can quickly and easily test policies and validate whether your desired security outcomes will be achieved. This endpoint allows you to simulate user access attributes, such as IP address, device, risk, and so on, to test whether the user will be granted access to the specified application. This endpoint is implemented in the Admin Console as the [Access Testing Tool](https://help.okta.com/okta_help.htm?type=oie&id=csh-access-testing-tool). The`/simulate` endpoint helps you identify potential security risks and compliance issues before you implement a policy. See [Policy API](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicySimulation) and [Test your policies with access simulations](/docs/guides/policy-simulation/). +With the Policy API `/simulate` endpoint, you can quickly and easily test policies and validate whether your desired security outcomes will be achieved. This endpoint allows you to simulate user access attributes, such as IP address, device, risk, and so on, to test whether the user will be granted access to the specified app. This endpoint is implemented in the Admin Console as the [Access Testing Tool](https://help.okta.com/okta_help.htm?type=oie&id=csh-access-testing-tool). The`/simulate` endpoint helps you identify potential security risks and compliance issues before you implement a policy. See [Policy API](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicySimulation) and [Test your policies with access simulations](/docs/guides/policy-simulation/). #### Universal Directory attribute and enum limits are GA in Production From cece182e1d7a09cfc5fbde653bc32a0f25fccf62 Mon Sep 17 00:00:00 2001 From: thomascavanagh-okta Date: Fri, 27 Sep 2024 17:02:44 -0400 Subject: [PATCH 7/8] Apply suggestions from code review #3 Co-authored-by: barbaravo-okta <87335401+barbaravo-okta@users.noreply.github.com> --- .../archive-configure-signon-policy/main/index.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/packages/@okta/vuepress-site/docs/guides/archive-configure-signon-policy/main/index.md b/packages/@okta/vuepress-site/docs/guides/archive-configure-signon-policy/main/index.md index d939fb2f9cb..10f517d34b4 100644 --- a/packages/@okta/vuepress-site/docs/guides/archive-configure-signon-policy/main/index.md +++ b/packages/@okta/vuepress-site/docs/guides/archive-configure-signon-policy/main/index.md @@ -4,7 +4,7 @@ excerpt: How to configure an Okta Sign-On policy and an app sign-on policy. layout: Guides --- -> **Note:** This document is only for Okta Classic Engine. If you’re using Identity Engine, see [Configure a global session policy and authentication policies](/docs/guides/configure-signon-policy). See [Identify your Okta solution](https://help.okta.com/okta_help.htm?type=oie&id=ext-oie-version) to determine your Okta version.” +> **Note:** This document is only for Okta Classic Engine. If you’re using Identity Engine, see [Configure a global session policy and authentication policies](/docs/guides/configure-signon-policy). See [Identify your Okta solution](https://help.okta.com/okta_help.htm?type=oie&id=ext-oie-version) to determine your Okta version. This guide explains what policies are, and how to add and configure Okta sign-on policies and app sign-on policies to your [Okta organization](/docs/concepts/okta-organizations/). @@ -28,11 +28,11 @@ This guide explains what policies are, and how to add and configure Okta sign-on An Okta sign-on policy helps you control who can sign in and how a user is allowed to sign in to Okta. Sign-on policies control whether users are challenged for MFA and how long they’re allowed to remain signed in before reauthenticating. You can also configure app sign-on policies for each app for extra levels of authentication before an app can be accessed. -Add a rule to the Okta sign-on policy. For example, add a rule that ensures that only users who are inside your [corporate network](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicyRule!path=0/conditions/network&t=request) can access your app. Or add a rule that excludes certain roles in your organization from accessing your app. Add a rule for an app sign-on policy, for example, to prompt groups that are assigned to your app to reauthenticate after 60 minutes. There’s only one app sign-on policy, but you can add as many rules to it as you need. +Add a rule to the Okta sign-on policy. For example, add a rule that ensures that only users who are inside your [corporate network](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicyRule!path=0/conditions/network&t=request) can access your app. Or add a rule that excludes certain roles in your org from accessing your app. Add a rule for an app sign-on policy, for example, to prompt groups that are assigned to your app to reauthenticate after 60 minutes. There’s only one app sign-on policy, but you can add as many rules to it as you need. -You can specify any number of Okta sign-on policies and the order in which they’re executed. If a policy in the list doesn't apply to the user trying to sign in, the system moves to the next policy. There’s one required organization-wide policy named **Default**. By definition, the default policy applies to all users. +You can specify any number of Okta sign-on policies and the order in which they’re executed. If a policy in the list doesn't apply to the user trying to sign in, the system moves to the next policy. There’s one required org-wide policy named **Default**. By definition, the default policy applies to all users. -In addition to the default policy, which you can't delete, there may be another organization-wide policy named **Legacy**. That policy is present only if you have already configured MFA. This policy reflects the MFA settings that were in place when you enabled your sign-on policy. And it ensures that no changes in MFA behavior occur unless you modify your policy. If required, you can delete it. +In addition to the default policy, which you can't delete, there may be another org-wide policy named **Legacy**. That policy is present only if you have already configured MFA. This policy reflects the MFA settings that were in place when you enabled your sign-on policy. And it ensures that no changes in MFA behavior occur unless you modify your policy. If required, you can delete it. > **Note:** See [Policies](/docs/concepts/policies) for an overview of the supported Okta policies and how they work. @@ -45,7 +45,7 @@ This guide provides step-by-step instructions to configure an Okta sign-on polic ## Prompt for an MFA factor for a certain group -The following are step-by-step instructions to configure an Okta sign-on policy. Use this policy to prompt a user for a factor (multifactor authentication (MFA)) when the user is a member of a certain group. +The following are step-by-step instructions to configure an Okta sign-on policy. Use this policy to prompt a user for Multifactor Authentication (MFA) when the user is a member of a certain group. ### Create the policy container From 149680b0905e40a8bfb3f7f9b0c7cc31dee3db1c Mon Sep 17 00:00:00 2001 From: thomascavanagh-okta Date: Fri, 27 Sep 2024 17:03:25 -0400 Subject: [PATCH 8/8] Update packages/@okta/vuepress-site/docs/guides/archive-configure-signon-policy/main/index.md Co-authored-by: barbaravo-okta <87335401+barbaravo-okta@users.noreply.github.com> --- .../docs/guides/archive-configure-signon-policy/main/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/packages/@okta/vuepress-site/docs/guides/archive-configure-signon-policy/main/index.md b/packages/@okta/vuepress-site/docs/guides/archive-configure-signon-policy/main/index.md index 10f517d34b4..5da8490e4a0 100644 --- a/packages/@okta/vuepress-site/docs/guides/archive-configure-signon-policy/main/index.md +++ b/packages/@okta/vuepress-site/docs/guides/archive-configure-signon-policy/main/index.md @@ -107,7 +107,7 @@ In addition to the Okta sign-on policy, there’s an app sign-on policy for each 1. In the Admin Console, select **Applications** > **Applications**. -2. Select the app that you want to configure a sign-on policy for. In this example, use a Web App. +2. Select the app that you want to configure a sign-on policy for. In this example, use a web app. 3. Click **Sign On** and scroll down to the **Sign On Policy** section.