Authentication and Authorization
Authentication is the process of confirming the alleged identity of a service requester; while several authentication methods are in use, authentication is most often performed by simple password verification.
Authorization, a process performed after authentication, determines the access or privilege level accorded an authenticated requester. Authorization answers two questions. Does this requester have access to a specific system resource (for example, a file or a configuration object)? If so, what kind of access (for example, create, destroy, or modify)? While there are several authorization methods, authorization is usually accomplished by assigning an authenticated requester to one of a number of pre-defined authorization classes. Conceptually, each class lists available objects, along with an associated object-access type (often expressed as read-only, write-only, or read-write).
Local Authentication and Authorization
This section describes user authentication and authorization performed locally by a Oracle OCSBC that has either the Admin Security or JITC feature set provisioned.
The feature sets provide two pre-defined user names
- user
- admin
Each of the two user names is associated with an eponymous authorization class which defines the access/privilege level for that user.
- provides read-only access to non-security configurations
- provides read access to visible files
- login to user mode
- cannot switch to admin mode
- provides read-write access to all configuration
- provides read/write access to a sub-set of file system elements
- login to admin mode
- cannot switch to user mode
Console Login
With the addition of the Admin Security feature, local login to the OCSBC is restricted to the two previously described usernames (user and admin) via the console/serial connection. The following table summarizes default authentication and authorization for local logins.
| User Name | Logins into/prompt | Authentication | Authorization |
|---|---|---|---|
| user | user mode
> |
authenticated locally by OCSBC via password | authorized locally by
OCSBC
assigned to user class inherits access/privilege defined by that class |
| admin | admin mode
# |
authenticated locally by OCSBC via password | authorized locally by
OCSBC
assigned to admin class inherits access/privilege defined by that class |
Serial Port Control
With the addition of the Admin Security feature, you may enable or disable access to the serial (console) port. In the absence of this feature, access to the serial is generally available. The ACLI command console-io functions as a switch that you set to enabled to allow serial port access and to disabled to keep the serial port from being used.
If you remove the administrative management feature after disabling the serial port, the OCSBC reverts to its default behavior by providing serial port access.
To turn off access to the serial port:
Initial Login
Upon initial login user and admin are required to change the respective password. Initial login is completed only after password change and acknowledgment of the login banner.
The following figure shows the initial login screen for the admin role (the user role views a nearly identical screen).
To complete initial login:
-
Enter the factory
default password in response to the
Password: prompt.
The factory default user password is acme; the factory default admin password is packet.
Initial admin Login (Console Access)
Remote SSH Login with Password
With the addition of the Admin Security feature, remote access, via the management interface (also referred to as wancom0), is available using SSH Version 2.
The following figure shows remote SSH access for both user and admin)
Remote SSH Login
The following table summarizes default authentication and authorization for remote SSH logins.
| User Name | Logins into/prompt | Authentication | Authorization |
|---|---|---|---|
| user | user mode
> |
authenticated locally by OCSBC via password | authorized locally by OCSBC assigned to user class inherits access/privilege defined by that class |
| admin | admin mode
# |
authenticated locally by OCSBC via password | authorized locally by OCSBC assigned to admin class inherits access/privilege defined by that class |
Remote SSH Login with Public Key
The previous section described password-based SSH authentication. Alternatively, with the addition of the Admin Security feature, you can authenticate using SSH public keys.
Prior to using SSH-public-key-based authentication you must import a copy of the public key of each user who will authenticate using this method. The public key identifies the user as a trusted entity when the Oracle OCSBC performs authentication.
During the SSH login, the user presents its public key to the OCSBC, which validates the offered public key against the previously obtained trusted copy of the key to identify and authenticate the user.
Importing a public key requires access to the device on which the public key was generated, or on which it is currently stored with its associated private key. Access is generally attained with a terminal emulation program such as PuTTY, SecureCRT, or TeraTerm.
-
If necessary,
repeat the above procedure to import additional user-specific public keys.
Note:
Imported SSH public keys are subject to the same expiration policies and procedures as passwords. An SSH public key’s lifetime is the same as a password, and it is subject to the same notifications and grace intervals. If an SSH public key expires, the admin user must import a new SSH public key for the user. To ensure continuity of access, the admin should import a new SSH public key prior to the key expiration.The following figure shows the successful SSH-public-key based authentication of Matilda, who has logged in with admin privileges, and Dwight who has logged in with user privileges.
Note in the figure above that the login banner refers to the admin and user login by the aliases used when the trusted copies of their SSH public keys were imported. In all respects, however, Dwight is a user instance, and Matilda is a admin instance.
The following table summarizes default authentication and authorization for remote SSH logins.
User Name Logins into/prompt Authentication Authorization not relevant user mode >
or
admin mode
#
authenticated locally by OCSBC via SSH public key authorized locally by OCSBC authorization determined by authorizationClass command argument (user or admin) inherits access/privilege defined by the specified class
Two-Factor Authentication
Two-factor authentication provides an extra level of security for the Oracle Communications Session Border Controller (OCSBC) by requiring users to enter a Passcode during login, in addition to their Username and Password credentials. Two-factor authentication applies to the Super User for both local and SSH login to the ACLI, and for HTTPS login to the Web GUI.
The two-factor authentication option requires the Admin
Security feature be provisioned, and you must enable the option by setting
login-auth-method to "two-factor" and
saving the configuration. After you set "two-factor" and save the
configuration, the
OCSBC prompts you to set
the Passcode.
The following illustration shows the configuration workflow on the ACLI.
SBC(configure)# security SBC(security)# admin-security SBC(admin-security)# login-config SBC(login-config)# login-auth-method two-factor SBC# save-config Checking configuration. ********************************************************* Admin passcode has not been set. Please set passcode now. ********************************************************* Enter New Passcode: Confirm New Passcode: Save-Config received, processing. Waiting for request to finish. Request to Save-Config has finished. Save complete.
The following illustration shows the user login experience on the ACLI after you enable two-factor authentication.
Username: ABCDEF Password: ***** Two Factor authentication mode enabled Passcode: -------------------------------------------------------------------------------- Last login : 2017-03-28 11:07:27 System last accessed by "admin", 2017-03-28 11:07:36 WARNING: Unsuccessful login attempts were made for 'admin' on 2017-03-28 11:12:24 -------------------------------------------------------------------------------- Confirm reading the above message [y/n]?: y
Passcodes must conform to the length and strength requirements specified in "Enable Two-Factor Authentication."
When you want to change the Passcode in the future, use the secret command that you also use for changing the Username and Password.
You can enable two-factor authentication only from the ACLI.
Two-factor authentication does not support RADIUS, TACACS, and HTTP.
Enable Two-Factor Authentication
To enable two-factor authentication for local or SSH login, you must set two-factor as the login authentication method and set the Passcode.
- Import the local certificate and the local certificate CA into the OCSBC.
- Configure the Web server for HTTPS.
- Provision the Admin Security feature.
The passcode must meet the following length and strength requirements:
- Must contain only upper and lower case alphabetical letters, numbers, and punctuation characters
- Must contain a minimum of fifteen characters
- Must contain two lower-case alphabetical letters
- Must contain two upper-case alphabetical letters
- Must contain two numerals
- Must contain two special characters
- Cannot contain, repeat, or reverse the user name
- Can not contain three of the same characters used consecutively
- Must differ from the previous passcode by at least four characters
- Must differ from the last three previous passcodes
- Cannot change more than once every 24 hours
RADIUS Authentication and Authorization
As an alternative to the local authentication/authorization described in previous sections, users may prefer to use a RADIUS server or server group for authentication and authorization.
For information on configuring between RADIUS servers and the OCSBC refer to RADIUS Authentication in the ACLI Configuration Guide .
A RADIUS users file (shown below), stored on the RADIUS server, provides the basis for server authentication and authorization decisions.
RADIUS Users File
Upon receiving a login request, the OCSBC sends a RADIUS Access Request message to the RADIUS server. The request message contains, among other things, the username:password requesting access to OCSBC resources. Upon receiving the request, the RADIUS server checks its user file for the username:password pair. If its finds a congruent match, the requestor is authenticated.
Successful authentication generates a Access Accept message to the OCSBC; the message also contains the contents of two Oracle Vendor Specific Attributes (VSAs). Acme-User-Class specifies the configuration privileges accorded the authenticated user. Acme-User-Privilege specifies the log file access accorded to the authenticated user. Together these two VSAs provide the authorization function. Consequently, the RADIUS server functions as an authentication and authorization decision point, while the OCSBC functions as an enforcement point.
RADIUS Authorization Classes
The RADIUS authorization classes, as specified by the Acme-User-Class VSA, do not coincide directly with those used to authorize the two pre-defined local usernames (user and admin). The RADIUS authorization classes are as follows:
user (RADIUS Acme-User-Class = user)
- provides read-only for all system configuration (including cryptographic keys and certificates)
- The login prompt for this user is ORACLE>
SystemAdmin (RADIUS Acme-User-Class = SystemAdmin)
- provides read-write access for system configuration (not including cryptographic keys and certificates)
- The login prompt for this user is ORACLE$
Admin (RADIUS Acme-User-Class = admin)
- provides read-write access for all system configuration (including cryptographic keys and certificates.
- The login prompt for this user is ORACLE#
RADIUS and SSH
When logging in via SSH and authenticating with RADIUS, username/password authentication for the two pre-defined user names (user, admin) is disabled. Attempts to login via SSH are rejected as shown in the following figure.
Local User Login with SSH (RADIUS Enabled)
If you want to enable user and admin access via SSH with RADIUS configured, you must explicitly define users on the RADIUS server with appropriate Acme-User-Class.
RADIUS and Password Policies
With RADIUS enabled, passwords are stored and controlled on the remote RADIUS server or servers. Consequently, none of the length/strength, re-use, history, or expiration requirements mandated by the local password policy are applicable to RADIUS passwords. Most RADIUS servers, however, do enforce password policies of their own.
TACACS+ Support
Note:
For SFTP, only TACACS+ users with admin privileges have permission to login.When TACACS+ is configured and a Public Key Infrastructure (PKI) user logs into the OCSBC, the OCSBC performs the authentication locally against the locally stored public RSA key, but performs authorization and accounting with TACACS+. This means that, instead of adhering to the permissions configured when importing the public key, the OCSBC queries the TACACS+ server and generates start/stop accounting records using TACACS+ settings.
