Authentication Realms
The authentication DBM's database can be partitioned into multiple authentication realms. (N.B.: These are not Kerberos or RADIUS realms.) Realms exist so that different departments can set their own policies with respect to authentication security. For example, department a might prefer a different password encryption type than department b. A primary Purdue realm will include all students, staff and faculty who have coordinated career accounts.
Authentication Realm Characteristics
-
Administrators. Each realm has a designated super-administrator (required) and zero or more sub-administrators.
The super-administrator is like the UNIX user "root"--all realm operations are allowed. The sub-administrators may be
given powers equal to or less than the realm's super-administrator. Super-administrators and sub-administrators are defined
in the realm configuration file.
-
Realm members. Realm administrators can join any person in the PUID database to their realm. The administrator may
also establish an initial password and install an X.509 certificate for the user. The administrator may also create an
access control list (ACL) for the user that specifies whether the user may modify his own password or install a new X.509
certificate. Realm administrators may also unjoin users from their realm.
-
Member policies. Some realms may trust their users more than other realms. For instance, a realm's security policies
might not permit its users to change their own passwords, preferring to have the realm administrator assign them. More liberal
realms might allow their users not only to change their own passwords, but to delegate that permission to other
realm members (e.g., a departmental proxy might change passwords for all I2A2 users in that department).
-
Encryption type. Passwords are not usually stored in the authentication DBM in a clear-text
or even retrievable form. Instead, passwords are used to encrypt a constant value and the resulting hash is stored (cf.
the UNIX crypt(3) function), or a message digest computed stored. Realms may select a
password encryption type from
a list of supported algorithms, or may choose to implement their own.
-
Authentication security policies. The authentication DBM keeps track of good and bad
authentication attempts on a per-user, per-realm basis. A realm's
authentication
security policy specifies what actions the I2A2 system should take in response to apparent attempts to guess a user's
password. The authentication policy can also
limit the number
of authentication attempts per second, to slow down "dictionary attacks."
- Realm trust relationships. Realms may choose to trust authentication credentials from other realms. For example, if a user authenticates to realm "a", and realm "b" trusts realm "a", the user is considered to be authenticated in both realms. Trust relationships are one-way: a realm "a" may trust a realm "b" that does not in turn trust realm "a". Two-way trust relationships must be explicitly established. Typically, a realm that uses a weak encryption method might choose to trust a realm that uses a strong one, but not vice versa.