How to Access the SBC

The primary interfaces used to access the 

are the Embedded Management Application (EMA) GUI, EMA in Platform Mode GUI, Command Line Interface (CLI) and BMC (Baseboard Management Controller) GUI and REpresentational State Transfer Configuration Application Processing Interface ().

EMA

The EMA provides a comprehensive method to provision, maintain and administer the

platform from any Web browser. This is the most frequently used access method. For more details, refer to the EMA User Guide.

For login details, refer to Logging Into EMA.

EMA in Platform Mode

The EMA in Platform Mode provides current status of the platform, application software version information and system information. The EMA in Platform Mode is also used to start, stop and restart the application as well as reboot the host. The EMA in Platform Mode supports upgrading the operating system and application. Additional features include a web interface for generic troubleshooting activities, security and remote access management.

For more information, refer to Logging into EMA in Platform Mode.

Command Line Interface

Command Line Interface (CLI) is the traditional method to configure systems from any machine with network access using a secure shell (SSH) client terminal emulator).

For login details, refer to Logging Into CLI.

Baseboard Management Controller

The Baseboard Management Controller (BMC) supports the following functions:

• View basic system information
• Change mouse mode
• Configure BMC and EMA in Platform Mode network settings
• Add, edit or remove users
• Configure NTP settings
• View or change SSL certificate
• Perform remote control settings
• Update BMC firmware and reboot BMC
• Switch to EMA in Platform Mode
• Integrated Lights Out Management (LOM)

For login details, refer to Logging Into the BMC

RESTCONF API

s provide access to RESTCONF API which is a simple, stateless architecture style (not a protocol) that uses the HTTP/HTTPS method ( such as GET, PUT, POST, DELETE) to retrieve the management information from the database. The main advantage is its simple interfaces and can be modified while the application is running.

RESTCONF has the following properties:

• Stateless: No client context is stored on the server. A request from the client will contain all the necessary information required to process the request.

• Client-Server model: In a client-server model, clients are associated with the user interface, and the servers manage data storage behind the interface. This allows a separation between the client and server.

• Cacheable: Improvement in scalability and performance when the client caches responses.
• Language–independent:
  Unable to show "metadata-from": No such page "_space_variables"
  uses open standards. Any language may be used to access the API ( C++, Java, etc. ) resources via URI paths.

To use a

, your application makes HTTPs requests and parses the responses. Currently, the only supported response format is XML. The methods used by developers are standard HTTP methods such as GET, PUT, POST, PATCH and DELETE. 

For access details, refer to Accessing RESTCONF API.

SOAP API

SOAP APIs provide access to Simple Object Access (SOAP) API which is protocol specification used to exchange structured information in the implementation of web services. It uses XML information set for its message format, and usually relies on other application layer protocols, such as Hypertext Transfer Protocol (HTTP) or Simple Mail Transfer Protocol (SMTP), for message negotiation and transmission. The advantage of using SOAP is that it is very versatile and uses different transport protocols. The standard stacks use HTTP as a transport protocol.

The SBC SOAP API supports the following requests for each managed object:

• CREATE – creates a managed object in the SBC.
• UPDATE – updates a managed object in the SBC.
• DELETE – deletes a managed object in the SBC.
• SHOW– retrieves managed object details from SBC.
• User defined operations – For example, manual switchover of the SBC.

The 

application maps each SOAP request to the corresponding RESTCONF request towards the SBC. In network configurations where is deployed, is also used to configure SBC Core using SOAP API for SBC. This interface supports provisioning as well the operations exposed by the yang models. For details, refer to the document "SBC SOAP API reference".

For access details, refer to Accessing SOAP API.

RAMP SBC Configuration Manager

If your network includes the 

platform, and the SBC is added as a managed node or is part of a managed cluster, you can access a web-based management interface from the EMS. The SBC Configuration Manager application provides GUI configuration and management options similar to what the EMA GUI provides. The SBC Configuration Manager is accessible under Node Management by navigating to the Node Inventory, Registration and Other Functions window (Network > Node Management > Function Manager) and selecting the Configure function for a node.  The SBC Configuration Manager is also accessible under Cluster Management by navigating to the Configurations tab for a cluster (Network > Cluster Management > Manage VNFs > Configurations) and clicking on the Edit Configure option. Refer to Ribbon Application Management Platform Documentation for more information on node and cluster management.

Single Sign-On for the SBC CNe and SBC SWe using RAMP

The SBC SWe and SBC CNe use a RAMP configured for CNe as the single point of authentication for the SBC when using the SBC RESTCONF API or the SBC CLI. This single sign-on feature applies when the SBC CLI and SBC RESTCONF APIs are proxied from RAMP to the SBC (without requiring any knowledge on RAMP of the semantics of the request).

The SBC is enhanced with the following capabilities:

• Accessing SBC's Confd CLI over SSH through RAMP.
• Accessing SBC's RESTCONF interface through RAMP.

Deployment for Single Sign-on through RAMP

In a deployment, end-users are authenticated and authorized by RAMP when they connect to the SBC. RAMP may interface with external identity providers for this purpose. After authentication, RAMP determines the usergroup that the user belongs to. RAMP passes on this user and usergroup information to the ConfD through the mechanisms mentioned below.

RAMP uses the existing 'emsadmin' user account to interface with the SBC. When the SBC registers with the RAMP, the LCA (Life Cycle Agent) on the SBC requests a password for the 'emsadmin' user account. The LCA updates this account on the SBC with the password generated and returned by RAMP in its response.

Accessing SBC's Confd CLI over SSH through RAMP

RAMP provides a web-based CLI terminal to the end-user. RAMP connects to the SBC's CLI port over the SSH, and proxy requests and responses from/to the end-user's web-based CLI terminal. RAMP connects to the SBC's CLI port as explained below:

• As the user: RAMP connects over the SSH to the SBC using the configured proxy admin user account (i.e proxyAdminUser and proxyCaleaUser) that the EMS uses to manage the SBC.

• End-user's username and groupname will be passed as the ssh ‘command’: The end-user's username and the groupname of the enduser's group is passed as arguments to the ssh command exactly as shown in the example below:

  ssh -t emsadmin@10.34.175.181 "alice admin"

Here, the first argument ('alice') represents the end-user's username. The last argument ('admin') represents the group to which the end-user belongs.

Accessing SBC's RESTCONF interface through RAMP

RAMP proxies the RESTCONF requests from the end-user over HTTPS, after substituting the end-user's credentials with a special set of credentials. RAMP connects to the SBC as shown below:

1. As the user: RAMP passes the end-user's username' in user field.

2. With a special password: The space (' ') , proxy admin username and groupname is appended to the password field in the format shown below:
   

   <space><ramp username>;<end-user's groupname>;<proxy admin user's password>

          Here, semi-colons are used to separate the various fields of the password.