Cyrus SASL Introduction

Cyrus SASL Introduction

1. Summary

This document describes how to configure SASL by a system administrator. It describes in detail how the system administrator uses the Cyrus SASL library to install a service.

2. SASL Concept

SASL stands for the simple authentication and security layer. Its mechanism is to verify the protocol. If a certain f service (such as SMTP or IMAP) uses SASL, the code will be shared among applications using this protocol. Some sasl-enabled applications include sendmail (later than 8.10.0) and Cyrus imapd (later than 1.6.0 ).

Applications using the SASL library will tell each other how to complete SASL protocol changes and the results after the changes.

SASL is just a framework, and a specific SASL mechanism controls accurate protocol changes. If n protocols use different m authentication methods, SASL tries to write data to the SASL database only using N + M, and does not need to write data to N * m for the first time, the application can use SASL to execute services.

3. authentication and authorization token

"Authorization identifier" and "authentication identifer" are different concepts. We need to be familiar with the differences between them.

Userid (User ID, authorization ID)

Userid is the identifier used by the application to check available options. For example, in Unix systems, the user "bovik" can be used to write "/home/bovik" and Its subdirectories, but cannot write "/etc ".

Authid (authentication ID)

"Authentication" is a token used for verification. For example, if the "bovik" password is "qqqq", the system will verify that any hacker who knows the "bovik" password is "qqqq. Such a user's role as another user is easily verified. Example: Harry is on vacation. He asked his student Jane to help him check his mailbox. He can let Jane assume his role. Jane only needs his ID and password verification, but needs to be authorized by the "bovik" user. In this way, Jane can log on to the mail system through "Jane" ID, Jane's password, and "bovik" user authorization.

Applications can set their proxy permissions. By default, SASL databases allow the same users to proxy other users (these users must be userid and authid ).

4. Fields

The Cyrus SASL Library supports domain definitions. A domain refers to the abstract set of user authentication in a specific domain and a specific mechanism.

In the simplest case of a single service on a single machine, a domain can be described as a service domain name. If the application does not have a specific SASL domain, most of the mechanisms use this method by default.

If a website wants to share the password among multiple machines, you can select the authentication domain name, such as "CMU. edu ". On the other hand, in order to prevent the security of a machine from exhausting the security of the entire website, each server can have its own field. Some mechanisms force users (clients) to manually configure their fields, making user authentication more robust.

A single site may support multiple different fields, which may cause application confusion, but the application does not want. You need to ensure that the application supports adding users from different fields to sasldb, and set saslpasswd.

The Kerberos Mechanism regards the SASL field as the Kerberos field. Therefore, the SASL field of Kerberos is the Kerberos default field on the server by default. They support cross-origin authentication; check how your application handles this SASL domain.

Some authentication mechanisms such as plain and CRAM-MD5 do not support domain concepts.

5. How SASL works and how servers and clients accurately select and use SASL to implement those authentication mechanisms

Plain

Plain itself does not have a security authentication mechanism. It uses other standard encrypted connections. (For example, the IMAP command "starttls" generates an encrypted connection by using plain .) The plain mechanism is to transmit a userid, an authentication ID, and a password to the server. The server verifies whether a triple transmitted by plain. The system administrator first focuses on how to authenticate and verify that the password is correct. The Cyrus SASL library can implement this function.

Passwd

/Etc/passwd can be well supported by the SASL library. The simple configuration is to set "pwcheck_method" to "passwd ".

Shadow

/Etc/shadow is a bit complicated. If the SASL library service is executed by the root user, there is no problem. You only need to set "pwcheck_method" to "shadow ". However, for security purposes, most daemon do not use root users, such as Cyrus imapd. To enable these services to check passwords, they need a root-run Helper Program or special permission to read/etc/shadow. The simplest way is to grant the service program permission to read/etc/shadow. For example, if you add a user group as the "shadow" Cyrus user, then the Cyrus user has the permission to read/etc/shadow.

Kerberos_v4

Kerberos V4 is configured during compilation. You can check the plaintext password by setting "pwcheck_method" to "kerberos_v4.

Pam

Pam verifies users in Linux and Solaris by default. You can check the password in different ways by configuring it. If you use PAM verification and the Cyrus SASL library, you only need to set "pwcheck_method" to "Pam" during compilation ". Pam authentication using SASL mechanism only applies to plaintext verification. It is ineffective to verify other passwords.

Sasldb

Sasldb is a dark-text database that stores SASL passwords. The same database stores the method of sharing dark files. First, the password of the shared key mechanism will be synchronized with the password of the plaintext mechanism. However, sasldb is not used in the general system. If you set a plaintext password in sasldb. You only need to configure "saslpasswd" to set pwcheck_method to sasldb.

Write your own

Finally, it is also the most important. Plain's most flexible verification method is to write your own authentication method. Some application entries use the "sasl_checkpass ()" convention or plain to call self-written verification code. The simplest way to modify verification conventions is to modify lib/server. C (for details ).

6. how to configure SASL

Default Configuration File

Generally, the Cyrus SASL library reads the configuration file from/usr/lib/SASL/APP. conf. The app is the name of the application. For example, Sendmail reads the configuration file from/usr/lib/SASL/sendmail. conf.

Application configuration

Applications can redefine how the SASL library looks for configuration information. For example, the ASL configuration item of Cyrus imapd reads sasl_pwcheck_option from its own configuration file/etc/imapd. conf.

Unfortunately, since SASL becomes more flexible, administrators can easily upgrade or install new authentication plug-ins without re-compiling the application. However, his flexibility also makes compilation cumbersome.