23.1983GPPOpen Service Access (OSA)Stage 2TS
6.1 Trust and Security Management Functions
The Trust and Security Management functions provide:
- the first point of contact for an application to access a network via the OSA APIs;
- the authentication methods for the application and network to perform a mutual authentication;
- the application with the ability to select a Service Capability Feature to make use of;
- the application with a portal to access other framework functions.
The process by which the application accesses the network via the OSA APIs has been separated into 3 stages, each supported by a different framework function:
1) Initial Contact with the framework;
2) Authentication to the framework;
3) Access to framework functions and Service Capability Features.
6.1.1 Initial Contact
The application gains a reference to the OSA Initial Contact function for the network that they wish to access. This may be gained through a URL, a Naming or Trading Service or an equivalent service, a stringified object reference, etc. At this stage, the application has no guarantee that this is a reference to the network, so it this reference to initiate an authentication process.
Initial Contact supports a particular method to allow the authentication process to take place (using the Authentication SCF defined in subclause 6.1.2). This method must be the first invoked by the application. Invocations of other methods will fail until authentication has been successfully completed.
Once the application has authenticated with the network, it can gain access to other framework functions and Service Capability Features. This is done by invoking a method, by which the application requests a certain type of access Service Capability Feature. The OSA Access function is defined in subclause 6.1.3.
Once the application has made initial contact with the network, and any time during their interactions, authentication of the application and network may be required.
The OSA APIs supports multiple authentication techniques. The procedure used to select an appropriate technique for a given situation is described below. The authentication mechanisms may be supported by cryptographic processes to provide confidentiality, and by digital signatures to ensure integrity. The inclusion of cryptographic processes and digital signatures in the authentication procedure depends on the type of authentication technique selected. In some cases strong authentication may need to be enforced by the network to prevent misuse of resources. In addition it may be necessary to define the minimum encryption key length that can be used to ensure a high degree of confidentiality.
The application must authenticate with the framework before it is able to use any of the other interfaces supported by the framework. Invocations on other interfaces will fail until authentication has been successfully completed.
6.1.3 OSA Access
This function supports stage 1 requirements related to authorization and service registration.
During an authenticated session accessing the Framework, the application will be able to select and access an instance of a framework function or Service Capability Feature.
In order to use OSA SCFs, the application must first be authorized to do so by establishing a service agreement with the network. The application uses the discovery SCF to retrieve the ID of the SCF they wish to use. They may then check that they are authorized to use the SCF. The network is informed that the application wishes to use the SCF. Finally, a service agreement is signed digitally between the two parties.
Establishing a service agreement is a business level transaction, which requires the HE-VASP that owns the application to agree terms for the use of an SCF with the Home Environment. Service agreements can be reached using either off-line or on-line mechanisms. Off-line agreements will be reached outside of the scope of OSA interactions, and so are not described here. However, applications can make use of service agreements that are made off-line. Some Home Environments may only offer off-line mechanisms to reach service agreements.
After a service agreement has been established between the application and the Home Environment domains, the application will be able to make use of this agreement to access the SCF.
Before an OSA SCF can be discovered, the application must know what "types" of SCFs are supported by the Framework and what "properties" are applicable to each SCF type. Once the HE-VASP finds out the desired set of SCFs supported by the network, it subscribes (a sub-set of) these SCFs using the Subscription framework function. The HE-VASP (or the applications in its domain) can find out the set of SCFs available to it (i.e. the SCFs that it can use).
6.3 Integrity Management functions
Integrity Management interfaces allow the framework to perform load management, heartbeat management, fault management and OAM functions as specified below.
6.3.1 Load Manager
The Load Manager function permits to manage the load on both the application and network sides.
The framework should allow the load to be distributed across multiple machines and across multiple component processes, according to a load balancing policy. The separation of the load balancing mechanism and load balancing policy ensures the flexibility of the load balancing functionality. The load balancing policy identifies what load balancing rules the framework should follow for the specific application. It might specify what action the framework should take as the congestion level changes. For example, some real-time critical applications will want to make sure continuous service is maintained, below a given congestion level, at all costs, whereas other applications will be satisfied with disconnecting and trying again later if the congestion level rises. Clearly, the load balancing policy is related to the QoS level to which the application is subscribed.
6.3.2 Fault Manager
The Fault Manager function is used by the application to inform the framework of events which affect the integrity of the framework and SCFs, and to request information about the integrity of the system.
6.3.3 Heartbeat Management
The Heartbeat Management function allows the initialization of a heartbeat supervision of the client application. In case of SCF supervision, it is the framework’s responsibility to check the health status of the respective SCF.
Since the OSA APIs are inherently synchronous, the heartbeats themselves are synchronous for efficiency reasons.
The OAM function is used to query the system date and time. The application and the framework can synchronize the date and time to a certain extent. Accurate time synchronization is outside the scope of the OSA APIs.
6.4 Registration of SCFs with the Framework
The Framework needs to know the Service Capability Features provided by the SCSs, in order to make them available to applications. For this purpose Service Capability Features have to be registered with the Framework, and they need to be registered in such a way that applications can discover them.
6.4.1 Service Registration
The Service Registration interface provides the methods used for the registration of SCFs with the Framework.
6.4.2 Service Factory
The Service Factory interface allows the Framework to get access to a manager interface of a SCF. It is used, in order to return an SCF manager interface reference to the application. Each SCF has a manager interface that is the initial point of contact for the SCF.