LOGIN_AS_ALLOWED

LOGIN_AS_ALLOWED_USERS

Platforms

All non-z/VM Classic/Classic HPO (no effect under Lite)

Abstract

Space-separated list of users who are allowed to login as any other user, without knowing that other user’s password. Intended for SSO support via X-LOGIN AS .

Example

z/VM:

Unix:

LOGIN_AS_ALLOWED_USERS="ssouser@example.com"

export LOGIN_AS_ALLOWED_USERS

Windows:

LOGIN_AS_ALLOWED_USERS=ssouser@example.com

Details

This variable setting controls the address (or addresses) which are allowed to use the X-LOGIN AS command for SSO login.

Similar to the other xxx_ALLOWED_USERS variables, this is a space-separated list of users who are allowed to login as any other user, without knowing that other user’s password. Normally you would define only one such user, but if you have multiple SSO scripts you may find it convenient to assign one username to each script to help track requests in the log.

Each user added to the setting requires a password, which may be set using the method of your choice. For instance the PWC command might be used to create a LISTSERV password. The password could also be an LDAP password, assuming the server is configured to use LDAP.

Before continuing, you must reach a point where you are able to login this user as itself using the regular ‘X-LOGIN user@domain [PW=xxx]’ command. Note that you are not required to use a password at all if you have access to another form of authentication. For instance, on a Windows domain with mandatory LDAP login, you would have to create a Windows user by that name so as to have the password in LDAP. You could then choose to run the SSO CGI script as that Windows username, and the script could then use LCMD and not need a hardcoded password for X-LOGIN.

Once you can log in the special user, you simply do:

X-LOGIN special_user AS target_user PW=pw_of_special_user

If the password being used contains spaces or special characters, you can use the HEXPW function to preserve those spaces or characters by encoding the password. This is done by placing the special HEXPW parameter either before or after ‘AS target_user’, e.g.,

X-LOGIN ssouser@example.com AS specialuser@example.com PW=b32r HL W!Zg]V+9G HEXPW

X-LOGIN ssouser@example.com HEXPW AS specialuser@example.com PW=b32r HL W!Zg]V+9G

By default, the command will return ‘***PRIVUSER***’ if target_user is a POSTMASTER. This may or may not make sense, depending on how you use the feature. In an open federation like Shibboleth, it is unlikely you will wish for random federation users to have control over who can login as root on your systems. In an enterprise with a closed internal network, it could very well make sense to have the central system authenticate all logins, which is essentially what happens when you login to a server as a Domain Admin account – nothing strange or fundamentally insecure about that. Nevertheless, if LISTSERV returns ‘***PRIVUSER***’, WA must fall back to the standard login page.

If you understand the potential issues, and still wish to have a POSTMASTER as a target user, you may enable X-LOGIN AS a privileged account by setting the LOGIN_AS_POSTMASTER_ALLOWED variable to "1".

Default Value

Not set.

Wildcards

Not allowed.