Add Sign On policies for applications
You can add an appAn abbreviation of application. Essentially, it is a web-based site used to perform any number of specific tasks, and requires authentication from end users by signing in.-based sign-on policy to allow or restrict access to applications.
Note: Some options described in this topic are Early AccessEarly Access (EA) features are opt-in features that you can try out in your org by asking Okta Support to enable them. Additionally, the Features page in the Okta Admin Console (Settings > Features) allows Super Admins to enable and disable some EA features themselves. features which may not be available in your orgThe Okta container that represents a real-world organization.. To enable them, contact Okta Support.
By default, all ClientEssentially, a client is anything that talks to the Okta service. Within the traditional client-server model, Okta is the server. The client might be an agent, an Okta mobile app, or a browser plugin. options in the App Sign On Rule dialog box are pre-selected. To configure more granular access to the app, selectively apply conditions as you create one or more prioritized rules based on:
- Who users are and/or the groupsGroups allow you to organize your end users and the apps they can access. Assigning apps to large sets of end users is made easier with groups. to which they belong
- Whether they are on or off network or within a defined network zone
- The type of client running on their device (Office 365 apps only)
- The platform of their mobile or desktop device
- Whether or not their devices are Trusted
Important to know about the User-Agent
Okta’s Client Access Policies (CAPs) allow you to manage access to your enterprise apps based on the client type and device platform. Okta CAPs evaluate information included in the User-AgentA software agent is a lightweight program that runs as a service outside of Okta. It is typically installed behind a firewall and allows Okta to tunnel communication between an on-premises service and Okta's cloud service. Okta employs several agent types: Active Directory, LDAP, RADIUS, RSA, Active Directory Password Sync, and IWA. For example, users can install multiple Active Directory agents to ensure that the integration is robust and highly available across geographic locations. request header sent from the users’ browser. Because the User-Agent can be spoofed by a malicious actor, you should consider using a whitelist approach when you create CAPs and require MFA or Device Trust as described in the following best practices:
- Implement a whitelist consisting of one or more rules that specify the client type(s) + device platform(s) + trust posture combinations that will be allowed to access the app.
- Require Device Trust or MFA for app access.
- Include a final catch-all rule that denies access to anything that does not match any of the CAPs preceding rules.
Important to know about MFA and legacy protocols
While you can configure your App Sign-On Policies to prompt end usersIn Okta literature, we generally refer to "end users" as the people who have their own Okta home page (My Applications), using chiclets to authenticate into all of their apps. End users do not have any administrative control. When we refer to "users" we are generally referring to the individual(s) who have administrative control. for MFA, be aware that legacy protocols such as POP or IMAP do not support MFA even if MFA is configured for Okta sign-in.
To ensure that authentication to apps remains secure, Okta strongly recommends that you evaluate the following:
- The use of legacy protocols with Microsoft Office 365 applications and whether to disable them if necessary
- Whether to enable Modern Authentication on Microsoft Office 365 tenants for improved security
- From the Administrative Dashboard, go to the Applications > Applications.
- Click the desired app.
- Click the Sign On tab.Screenshot
- Scroll down to the Sign On Policy section.
- Create a rule:
- Click Add Rule.
- Enter a name in the Rule Name field.
- Decide to whom the rule will apply by selecting an option under the People section.
- Users assigned this app – Specify the users who are assigned this specific app.
- The following groups and users – Assign the rule to groups or specific users who have been assigned the app.
Location — Specify the location to which you want the policy to apply. Available options are Anywhere, In Zone, or Not in Zone.
If you select In Zone, enter the name of a zone. You configure zone names in Security > Network. For details, see Network.
Client — Choose the conditions that you want to trigger the action(s) you configure in the Access section:
- (Microsoft Office 365 apps only) Under If the user's client is any of these, select the client type(s) that you want to trigger the action(s) you configure in the Actions section (Web browser or Modern Auth client). For details, see Office 365 Client Access Policies.
- Under And the user's platform is any of these, select the mobile and/or desktop platforms that you want to trigger the action(s) you configure in the Access section.
Device Trust — Specify the trust status of the device that you want to trigger the action(s) you configure in the Access section. The Trusted and Not Trusted options are only selectable if Device Trust is configured in Security > Device Trust. Okta Device Trust determines devices to be trusted based on the presence of a trust signal (MDM enrollment; certificate; support for Universal Links).
- In the setting When all the conditions above are met, sign on to this application is select either Allowed or Denied.
- (SAMLAn acronym for Security Assertion Markup Language, SAML is an XML-based standard for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). The SAML standard addresses issues unique to the single sign-on (SSO) solution, and defines three roles: the end user, the IDP, and the SP.
Here's how SAML works through Okta:
SP-initiated flow: the end user requests (principally through a browser) a service from the SP. The SP requests and obtains an identity assertion from the IdP (in this case, Okta). On the basis of this assertion, the SP can decide whether or not to authorize or authenticate the service for the end user.
IdP-initiated flow: with Okta as the IdP, an end user goes to the Okta browser and clicks on a chiclet, sending a SAMLResponse to the configured SP. A session is established with the SP, and the end user is authenticated. apps only) Select Prompt for re-authentication and specify how frequently you want users to be prompted to re-authenticate. The time period you specify begins from the moment the user last authenticated into Okta. This feature is available for all SAML-configured apps.
Note: Because SWAAn acronym for Secure Web Authentication. SWA is a SSO system developed by Okta to provide single sign-on for apps that don't support proprietary federated sign-on methods or SAML. Users can enter their credentials for these apps on their homepage. These credentials are stored such that users can access their apps without entering their credentials each time. When users first sign-in to a SWA app from their homepage, they see a pop-up message asking if they were able to sign-in successfully. apps do not support re-authentication, you cannot change the sign-on method from SAML to SWA if re-authentication is selected.
- Select Prompt for factor if you want to require users to choose an MFA option, and then specify how frequently you want users to be prompted. The Multifactor Settings link takes you to the Multifactor Authentication page, where you can choose your factor(s).
Set rule precedence by clicking the blue arrows to set the priority number. A rule with a priority value of 1 has first priority and takes precedence over all other rules.
- To edit a rule, click the pencil icon and select the Edit rule option.
- To disable a rule, click the pencil icon and select the disable rule option.
- To delete a rule, click the X icon.Screenshot
If a user is blocked from an app, the following message will be displayed: