Single sign-on
Single Sign-On (Single Sign-On) is a solution for identity authentication and authorization, allowing users to use the same login credentials in multiple related systems, you can access multiple systems by logging on at a time, providing a convenient and fast user experience.
Dedicated YIDA single sign-on function, which can be integrated into other systems or products. Members can directly use various functions of YIDA by logging on to the system or product once without additional login, improve work efficiency.
The main advantages of single sign-on include:
- Convenient user experience: users can access multiple systems with only one login authentication, without frequent user names and passwords, which improves user experience and work efficiency.
- Improved security: SSO uses a centralized identity authentication service to verify the user's identity, avoiding the security risks of storing user passwords in each system and reducing the risk of password leakage.
- Simplified Management: because users only need to maintain one login credential, the workload of user management is reduced, and the burden on system administrators is also reduced.
Working Principle
Supported protocols
Dedicated YIDA currently supports single sign-on for OAuth 2.0, OIDC, and CAS protocols. The following example uses OAuth 2.0 to describe how to get through IDAAS single sign-on.
OAuth 2.0
Is an open standard protocol for authorization that allows users to authorize third-party applications to access resources stored in another application without sharing their credentials. It provides a secure, flexible and standardized way to authorize and protect users' privacy and data security. OAuth 2.0 protocol is widely used in various scenarios, such as social media login, API access control, single sign-on, etc., providing better interconnection experience for users and developers.
Protocol main process
- The dedicated YIDA has the single sign-on function and acts as a service provider (SP) in it.
- First, the Enterprise Administrator enables the single sign-on function. When an employee who is not logged on needs to log on to YIDA, the system directs the page request to the identity provider (IdP) address preset by the administrator.
- If the member has already logged on to IdP, IdP only needs to read user information from the session and return the information to YIDA through administrator configuration.
- If the member has not logged on to IDP, enter relevant information to log on to IDP. After logging on, return the information to YIDA.
- YIDA after receiving the user information, call the DingTalk address book interface to identify the user identity, and then provide services to the user.
Description:
- IdP is the abbreviation of Identity Provider, which refers to the authentication center. IdP holds user information and establishes sessions with users during the authentication process.
- SP is the abbreviation of Service Provider, which refers to the Service Provider. When a user accesses the Service provided by SP, if the SP cannot identify the user, it will request IdP to authenticate the user.
For example, IdP-IDAAS, SP-exclusive YIDA
Configuration method
Prerequisites: to provide a public network interface that can be connected to the Internet, the user information interface must return DingTalk uid or userId (based on the DingTalk account system)
Take Alibaba Cloud IDAAS and OAuth 2.0 as examples to demonstrate how to log on to DingTalk through IDAAS authentication service configured with YIDA authentication system.
Configuration in IDAAS
- Create an OAuth 2.0 protocol application (similar to OIDC and CAS protocols)
- Configure application information
- Redirect URI: the YIDA page address you want to jump to after logging in successfully. The format is YIDA homepage. For example, your homepage address is https://xxxx.aliwork.com.
- GrantType: Select authorization-code mode, standard OAuth 2.0 process
- Other configuration items are generally set according to Page recommend.
- Application authorization configuration: The application can be authorized according to different dimensions on the IDAAS side. Only users within the authorization scope can authenticate the application.
- View Application Information
- The information items that need attention are: client Id, client Secret, authorize URL, accessToken address, Redirect URI
- client Id and client Secret: YIDA the parameters that need to be carried when initiating the request. IDAAS verifies the parameters to uniquely determine the application on IDAAS.
- authorize URL: YIDA the link to request IDASS to obtain the authorization code.
- accessToken address: YIDA the link to request IDASS to obtain the token.
- Redirect URI: the link entered for the application creation.
Configuration in YIDA
After creating and authorizing applications on the IDAAS side, the administrator enters the YIDA side to enable single sign-on and complete relevant configurations.
- Enable SSO single sign-on
- Configure single-point logon information (select one of the logon protocols. The following figure takes OAuth2 as an example)
- After the configuration is saved, log out and log on again to verify that you are logged on to the single sign-on service,Effective for the whole organization.
YIDA SSO protocol format example
The returned identity callback data must meet the following format
OAuth2
{
"success": true,
"code": 200, //状态码
"data": {
"sub": "钉钉uid或者钉钉userId"
}
}
OIDC
The user information returned by parsing based on the configured public key is in the following format. The sub is used on the YIDA side.
{
"sub": "钉钉uid或者钉钉userId",
"iss": "http://xxxxxx/public/api/application/plugin_oidc/oidc",
"aud": "xxxxxxx6CPpztCvzN6tjB",
"uuid": "xxxxxxx2baed8e7a77zqtOGeqBXbm",
"username": "admin",
"email": "xxxxxx@qq.com"
}
CAS
<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
<cas:authenticationSuccess>
<cas:attributes>
<cas:externalId>钉钉uid或者钉钉userId</cas:externalId>
</cas:attributes>
</cas:authenticationSuccess>
</cas:serviceResponse>
Introduction to some common concepts
Concept | Description |
Identity Provider (IdP) | A RAM entity that contains metadata about external identity providers. Identity providers can provide identity management services.
|
Service Provider (SP) | For applications that use the identity management function of IdP to provide users with specific services, SP uses the user information provided by IdP. Some non-SAML identity systems (for example, OpenID Connect) also refer to service providers as trusted parties of IdP. |
Security Assertion Markup Language (SAML 2.0) | The standard protocol for enterprise-level user identity authentication is one of the technical implementation methods for communication between SP and IdP. SAML 2.0 is a fact standard for implementing enterprise-level SSO. |
SAML assertion (SAML assertion) | The SAML protocol describes the core elements of authentication requests and authentication responses. For example, the user's specific attributes are included in the authentication response assertion. |
Trust | The mutual trust mechanism established between SP and IdP is usually implemented by public key and private key. SP obtains the SAML metadata of IdP in a trusted way. The metadata contains the signature verification public key of IdP issuing SAML assertion, and SP uses the public key to verify the integrity of assertion. |
OIDC | OIDC(OpenID Connect)Is built onOAuth 2.0Based on an authentication protocol. OAuth is an authorization protocol, while OIDC builds an identity layer on the OAuth protocol. In addition to the authorization capability provided by OAuth, it also allows clients to verify the identity of end users, and obtain basic user information through the OIDC API(HTTP RESTful form). |
OIDC token | OIDC can issue an identity Token representing the logged-in user to the application, that is, the OIDC Token (OIDC Token). The OIDC token is used to obtain the basic information of the logon user. |
Client ID | When your application registers with an external IdP, it generates a Client ID(Client ID). When you apply for an OIDC token from an external IdP, you must use the client ID. The issued OIDC token will also passaudThe field carries the client ID. Configure the client ID when creating the OIDC identity provider, and then use the OIDC Token for STS Token, Alibaba Cloud verifiesaudWhether the client ID carried by the field is the same as the client ID configured in the OIDC identity provider. Roles are allowed only when they are consistent. |
Verify fingerprint | To prevent the issuer URL from being hijacked or tampered with, you need to configure the authentication fingerprint generated by the HTTPS CA certificate of the external IdP. Alibaba Cloud will automatically calculate the verification fingerprint, but we recommend that you calculate it locally (for example, useOpenSSLFingerprint calculation), compared with the fingerprint calculated by Alibaba Cloud. If the comparison is different, the issuer URL may have been attacked. Please confirm again and fill in the correct fingerprint. |
Issuer URL | The issuer URL is provided by an external IdP and corresponds toissThe value of the field. The issuer URL must behttpsStarts with a standard URL format, but does not allow query parameters (?ID), fragment fragments (#Identification) and login information (@ID). |
Temporary identity credentials | STS(Security Token Service)It is a temporary access management service provided by Alibaba Cloud. STS is used to obtain temporary identity credentials (STS Token) that can customize the validity period and access permissions. |