Need for provisioning

Provisioning is a function where Okta and SaaS work together to automatically manage the account lifecycle.

With the spread of cloud services, it has become necessary to create, change, or abolish accounts and set privileges depending on the user's status (joining, transferring, retiring) for each service. By using Okta's provisioning feature, you can centrally manage the status of your SaaS ID by simply managing Okta user information and attributes.

Provisioning to non-SCIM-enabled SaaS

Generally, when provisioning to SaaS, a protocol called "SCIM" is used. However, there are still many SaaS that do not support SCIM, and because they are using SaaS that do not support SCIM, there are cases where they give up on automating ID management through provisioning. Some of the SaaS you are using may not be compatible with SCIM.

Okta Workflows realizes provisioning for such SaaS. Okta Workflows allows you to send requests using SaaS APIs, so as long as the SaaS side has APIs for user creation/update/invalidation/deletion, you can automate ID management for any SaaS. is. Furthermore, for typical SaaS used by many companies such as Microsoft Office 365, Google, and Box, you can use pre-prepared cards (see the figure below) for each SaaS to handle the necessary information for API requests. There is no need to manually enter header and body information, making the setup extremely easy.

Box user creation flow example

By using Okta Workflows, you can expand the possibilities of automating SaaS, which you had previously given up on provisioning!

ID/access authority inventory issues

Companies use a variety of SaaS, and among those companies, companies with group companies or subsidiaries may have SaaS that can only be used by head office users or SaaS that can only be used by subsidiary users. Furthermore, even within a single company, there are many cases in which the SaaS that can be used differs depending on department or position.

In such a case, for example, if a user who has been transferred or seconded is still given access privileges to SaaS that can only be used by users in the department or company to which he or she originally belonged. Risk of unauthorized app use due to inappropriate access privileges there is.

However, manually inventorying SaaS access privileges, which are divided by each department and company, every time a transfer or secondment occurs is extremely time-consuming and may lead to human error. yeah.

Automatic notification to administrator of SaaS access privilege inventory

With Okta Workflows, by using the APIs of Okta and SaaS, you can check ``users who have been granted access privileges to the target SaaS on the Okta side and their access status to the SaaS'', and ``users existing on the SaaS side.'' ” on a regular basis and extract “users who have not accessed the site for a certain period of time (can be specified)” = “users whose access privileges need to be inventoried”.

Furthermore, by linking with communication tools such as email, Microsoft Teams, and Slack, administrators can be notified of the extracted users who require an inventory of access privileges, so administrators can follow the notification contents. Taking inventory helps reduce man-hours and human errors.

If you have been having trouble with ID inventory work, why not take this opportunity to consider improving the efficiency of your inventory?

*Okta also has a function called ``Access Certification'' in ``Okta Identity Governance'' that further streamlines the inventory of IDs and privileges. If you are interested in more details, please also refer to the blog below.

https://www.macnica.co.jp/business/security/manufacturers/okta/access_certification.html

The importance of device control

"Device control" introduced here refers to allowing authentication only from devices authorized by the organization. Device control has recently been attracting attention from a security perspective, but why is this type of control important?

There are two main reasons:

Device control hurdles

We understand the importance of device control, but is this authentication method easy for any company to implement?

Typical device control is implemented by distributing certificates to target devices and checking the certificates during authentication. In this case, you will need a service that ` `manages authorized devices with a device management solution'' and ` `distributes certificates to devices.''

However, not all companies have implemented device management solutions such as MDM, so in many cases companies must first consider implementing such services and end up giving up. While device authentication control is highly important, it is a difficult authentication method for companies that do not have a device management solution in place.

MDM/certificate-free device authentication control

Although this authentication method has a high hurdle, there is a way to implement device authentication control without MDM/certificates by using Okta Workflows.

Okta allows access policies to allow access only from devices registered in your organization's Okta tenant.

With Okta Workflows, you can use Okta's API to manage the registration status of devices on Okta, so by controlling the registration status of unauthorized devices, you can use MDM and certificates. Device authentication control that allows access only from authorized devices is possible without having to do so.

*Depending on the device OS, MDM and certificates may be required. The above method is available for Windows and MacOS.

*Okta also has a function (device trust) that allows you to control devices using certificates by linking with any device management solution.