Help Center/ OneAccess/ Best Practices/ OneAccess Best Practices
Updated on 2024-12-30 GMT+08:00

OneAccess Best Practices

This section summarizes best practices of OneAccess in common scenarios. Each practice is given a description and procedure.

Table 1 Best practices for identity source integration

Practice

Description

Integrating AD

OneAccess allows you to import user and organization information from AD and synchronize the information in real time via LDAPv3.

Integrating LDAP

OneAccess allows you to import user and organization information from LDAP and synchronize the information in real time via LDAPv3.

Table 2 Best practices for application integration

Practice

Description

Logging In to the Huawei Cloud Through User Portal

Huawei Cloud supports single sign-on (SSO) based on SAML and OpenID Connect. After enterprise administrators configure Huawei Cloud and OneAccess, common users can log in to the OneAccess user portal to access the Huawei Cloud console or a specific Huawei Cloud application without entering a password.

SSO Access to Applications Through SAML

Security Assertion Markup Language (SAML), developed by the Security Services Technical Committee of OASIS, is an open-source standard data format based on XML. SAML exchanges authentication and authorization data between different security domains, meeting the SSO requirements of web applications.

SSO Access to Applications Through OAuth 2.0

OAuth 2.0 is an open standard that allows users to authorize third-party applications to access their information stored on a specific resource server without sharing usernames and passwords with the third-party applications.

SSO Access to Applications Through OIDC

OpenID Connect (OIDC) is a standard identity authentication protocol that runs on top of the OAuth 2.0 protocol. For more information about OpenID Connect, see OpenID Connect Introduction.

This section describes how to integrate an application with OneAccess using the OIDC protocol.

SSO Access to Applications Through CAS

CAS is an HTTP2- and HTTP3-based protocol which requires that each component be accessed through a specific URL. You can configure OneAccess as an identity service provider through CAS to enable third-party applications to read user account data from OneAccess. CAS 1.0, CAS 2.0, and CAS 3.0 are supported.

SSO Access to Applications Through Plug-in Autocompletion

OneAccess can integrate applications that do not support standard protocols (including OAuth 2.0, SAML, OpenID Connect, and CAS) and cannot be reconstructed on a PC.

This section describes how to integrate an application with OneAccess through plug-in autocompletion.

Table 3 Best practices for data synchronization

Practice

Description

Synchronizing Data to Atlassian Through SCIM

System for Cross-domain Identity Management (SCIM) is designed to manage multi-tenant identities for cloud-based applications. SCIM 2.0 is built on an object model where a resource is the common denominator and all SCIM objects are derived from it. SCIM 2.0 has id, externalId, and meta as attributes. RFC 7643 defines User, Group, and EnterpriseUser that extend the common attributes.

This section describes how to synchronize user data to Atlassian through the SCIM protocol.

Synchronizing Data Through LDAP

LDAP is a lightweight directory access protocol. LDAP can be considered a tree-like database that stores user and organization information. One of the main application scenarios of LDAP is SSO where users are automatically logged in to internal networks of their company after logging in on a PC for once.

Table 4 Best practices for authentication provider integration

Practice

Description

Built-in Authentication Providers

This practice describes how to add a FIDO2 authentication provider (such as facial or fingerprint biometric authentication) to log in to applications on OneAccess.

SAML Authentication

OneAccess allows you to configure the SAML protocol as the authentication provider to log in to each application system for better user experience.

OIDC Authentication

OneAccess allows you to configure the OIDC protocol as the authentication provider to log in to each system for better login modes and experience.

OpenID Connect (OIDC) is a standard identity authentication protocol that runs on top of the OAuth 2.0 protocol. For more information about OpenID Connect, see OpenID Connect Introduction.

CAS Authentication

CAS is an HTTP2- and HTTP3-based protocol which requires that each component be accessed through a specific URL. You can configure OneAccess as a service provider using the CAS protocol to enable user accounts of third-party applications to access OneAccess. CAS 1.0, CAS 2.0, and CAS 3.0 are supported.

The CAS protocol involves two entities: CAS client and CAS server. They exchange information through users' browsers. For example, a CAS client returns a redirect message containing parameters and forwards the message to the CAS server. If the login authentication is successful, the CAS server returns an XML response containing the user information to the CAS client. After authenticating the user information, the CAS client returns the requested resource to the user.

  • CAS client: resource provider, for example, third-party applications.
  • CAS server: identity authentication provider. For example, OneAccess can be considered as an identity authentication provider.

OneAccess allows you to configure the CAS protocol as the authentication provider. You can use the CAS protocol to log in to each application system and implement single sign-on (SSO) between application systems.

OAuth Authentication

OAuth is an open standard that allows users to authorize third-party applications to access their information stored on a specific resource server without sharing usernames and passwords with the third-party applications.

OneAccess allows you to configure the OAuth protocol as the authentication provider. You can use the OAuth protocol to log in to each application system.

Kerberos Authentication

Kerberos is a computer-network authentication protocol that allows nodes communicating over a non-secure network to prove their identity to one another in a secure manner. For details, visit https://web.mit.edu/kerberos.

AD is a database that stores network objects, allowing administrators and users to search for required information.

Service Principal Name (SPN) is a unique identifier of a service instance.

It associates a service instance with a service account during Kerberos authentication. SPNs must be registered for the server under a built-in computer account or user account. For built-in accounts, SPNs are automatically registered. To run services using a domain account, manually register an SPN for the account.

OneAccess allows you to configure the Kerberos protocol as the authentication provider. You can use the Kerberos protocol to log in to each application system.

AD Authentication

Active Directory (AD) is a database that stores network objects, allowing administrators and users to search for required information.

To facilitate user authentication, OneAccess uses LDAP to direct the authentication to the AD domain. After the AD authentication succeeds, OneAccess matches the user attributes returned by the AD domain with the user association attributes in OneAccess. If the authentication is successful, the user can log in to OneAccess.

LDAP Authentication

Lightweight Directory Access Protocol (LDAP) is a lightweight directory access protocol.

LDAP can be considered a tree-like database that stores user and organization information. One of the main application scenarios of LDAP is SSO where users are automatically logged in to internal networks of their company after logging in on a PC for once.

Table 5 Other best practices

Practice

Description

Authorizing IAM Users to Access a OneAccess Instance Administrator Portal

You can use your account to create IAM users and assign permissions for specific resources. Each IAM user has their own identity credentials (password and access keys) and uses cloud resources based on assigned permissions.

IAM users can access OneAccess instances, helping the enterprise administrator to securely control access to OneAccess resources.

API Usage

OneAccess provides a third-party API authorization management function. API providers configure APIs in OneAccess first. To use these APIs, API consumers obtain authentication tokens from OneAccess, and call the APIs with the authentication tokens. The API providers then determine whether to provide services to the API consumers based on the authentication tokens.

Configuring MFA for User Login

OneAccess supports MFA during user login, which is more secure. This section uses the user portal as an example to describe how to configure and use MFA.