Security at Okta

Okta is the foundation for secure connections between people and technology. Functionality for user authentication, password and access management, integration with on-premise user directories, and analysis of cross-application usage requires that Okta remains secure and highly available.

 

The Okta approach to security is based on the following principles:

 

Platform

The Okta software platform is designed to provide a secure and reliable foundation for functionality to scale and manage cloud applications. This ensures that communications with Okta are secure and verified, control and access to the Okta service can be delegated across an organization, and that customer data remains secure. Additional security measures prevent cross-site scripting, forgery requests and SQL injections. Okta works with external security experts to validate the security of our design and implementation.

 

Domain access

All access to Okta uses the https protocol. Customers are assigned their own domains, sub-domains, and cookies. In order to protect Production and Preview services, controls are implemented, audited, and attested as part of our SOC 2 Type II report, which is available under NDA upon request. Okta also holds US-EU and US-Swiss Safe Harbor certifications.

Okta uses strong encryption to secure sensitive customer data such as unique 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 an app, sending a SAMLResponse to the configured SP. A session is established with the SP, and the end user is authenticated. keys that are created for authentication. We also store and encrypt credentials that users submit for downstream 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. applications (apps), configured within their SSOAn acronym for single sign-on. In a SSO system, a user logs in once to the system and can access multiple systems without being prompted to sign in for each one. Okta is a cloud-based SSO platform that allows users to enter one name and password to access multiple applications. Users can access all of their web applications, both behind the firewall and in the cloud, with a single sign in. Okta provides a seamless experience across PCs, laptops, tablets, and smartphones. environment.

Okta does not implement any proprietary encryption. Customer data encryption is performed at the application layer.

Note the following about encryption and keys:

  • Okta encrypts the tenant confidential data in the database. The encryption is performed using symmetric encryption 256-bit AES with exclusive keys per tenant. Tenant exclusive symmetric keys ensures data segregation
  • Tenant-exclusive keys are stored in a tenant exclusive keystore. The keystore can be accessed only with a tenant-exclusive master key.

  • Tenant-exclusive master keys are encrypted in three different ways to achieve the highest level of availability and business continuity.

The use of application level encryption protects sensitive data, even in the event of partial compromise. As a result, attackers lack the ability to decrypt the data if armed with 2 out of 3 of the following: Master Key, Key Store, and/or the user's 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. context.

 

Customer data

Okta takes several steps to secure customer data. For all queries, retrievals, and bulk updates, the Okta service returns or updates only validated data. Data is validated for each requestor in the context of the customer subdomain, https://<customername>.okta.com, and https://<customername>.oktapreview.com.

All Okta system responses to a request are subject to any access restrictions in place for that customer and their Okta registered users. This user/customer relationship is revalidated on every request to ensure that only authorized users within the customer’s subdomain view the data.

 

Operations

Technical teams at Okta have a wide range of experience developing and operating market leading on-demand services. A comprehensive evaluation of infrastructure providers was performed in order to select the right partner for security and scalability of services.

Okta and Amazon (AWS) have a comprehensive approach to ensure security and reliability of the Okta service. It starts with the physical data center, extends through the compute, network, and storage layers of the service, and is complimented by well-defined access policies and ongoing audit and certification by third parties including SAS 70 Type II Certification and SSAE 16 (SOC 2) Certification.

 

SSO and Directory integration

Many SaaS applications today support integration with single sign-on (SSO) solutions that adhere to the Security Assertion Markup Language (SAML) standard. Okta provides single sign-on capability and, for SAML compliant applications (service providers), Okta serves as a SAML Identity Provider (IdPAn acronym for Identity Provider. It is a service that manages end user accounts analogous to user directories such as LDAP and Active Directory, and can send SAML responses to SPs to authenticate end users. Within this scenario, the IdP is Okta.). The Okta service has the ability to respond to SAML requests from those applications with a SAML assertion response and facilitate secure user authentication.

 

Web Authentication

Okta provides reliable integration for single sign-on (SSO) to all your web and mobile apps, with a full-featured federation engine and flexible access policy, including sign-on to applications that do not provide support for federated single sign-on.

 

Active Directory integration

For many organizations, Active DirectoryActive Directory (AD) is a directory service that Microsoft developed for the Windows domain networks. It is included in most Windows Server operating systems as a set of processes and services. Initially, Active Directory was only in charge of centralized domain management. (AD) is the core repository of users and the associated credentials that are used to govern access to network and application resources. Okta integrates with AD to extend this capability to cloud based applications and enables automated user import, provisioning, deprovisioning, and authentication against AD.

 

Network

The AWS network provides protection against traditional network security issues including Distributed Denial Of Service attacks (DDoS), Man In the Middle (MITM) attacks, IP spoofing, port scanning, and packet sniffing by other tenants.

 

Permissions model

Okta uses a robust permissions model that allows very specific control while remaining extensible.

 

Vulnerability protection

Core security features of the underlying Okta platform include the ability to prevent Cross-Site Scripting (XSS), Cross-Site Request Forgery (XSRF), and SQL Injection attacks. Strong validation of input and requests and strict programmatic controls on SQL statements minimize these threats.

 

Third-party penetration testing

As part of our security strategy Okta hired a third party security testing firm, iSEC Partners, to perform penetration testing in an effort to understand and improve overall service security. The assessment included design review, source review and penetration testing. All testing was done using white box testing methodology, which entailed providing iSEC Partners with access to source code, binaries, technical documentation, and key developers. Okta developers worked hand in hand with the iSEC testing team to identify security threats and develop solutions to any potential threats.

 

Server and physical access

Each server in the Okta environment is monitored for machine health metrics twice per minute to track availability. AWS data centers are housed in nondescript facilities. Physical access is strictly controlled both at the perimeter and at building ingress points by professional security staff utilizing video surveillance, state of the art intrusion detection systems, and other electronic means. Authorized staff must pass two-factor authentication a minimum of two times to access data center floors. All physical access by employees is logged and routinely audited.

Administrative access to the host operating systems to manage instances requires the use of multi-factor authentication. The administrative hosts systems are specifically designed, built, configured, and hardened to protect the management plane of the cloud. All access is logged and audited. Guest OS environments are locked down and completely controlled by Okta administrators. AWS has no access rights to the guest OS.

 

Hiring practices

Security starts with the people we employ. Background checks are performed on all candidates for Okta and employees, contractors and third party users must confirm in writing that they understand their roles and responsibilities regarding information security as part of their employment or vendor contract.

 

 

 

 

Top