Product Description
 |
 |
 |
|
 |
Get Adobe Reader |
Policy
The following sections describe WebLogic Network Gatekeeper policy functionality:
Overview
The WebLogic Network Gatekeeper's behaviour in relation to the service providers, applications and the networks can be easily changed to fit an operator specific context. This is achieved using rule based policies together with a mix of internal and external data sources.
The WebLogic Network Gatekeeper distinguish between core and custom policies. The core policies are general policies that are a standard part of the WebLogic Network Gatekeeper. Their main usage areas are authentication, authorisation, service capability access, and usage control.
Custom policies are operator specific policies defined by the operator and implemented by BEA Systems or a selected partner.
Core policy areas
Authentication
Authentication policies are applied on service provider and application level. They define the configurable parts of the authentication process between an application and WebLogic Network Gatekeeper. Using these policies, the authentication process can be customized to fit the relation between the operator and the service provider.
Authorisation and access control
Access control policies are applied on service provider and application level and defines both which service capabilities and which functions within a service capability an application is allowed to use. Using the policies the operator can provided customized service offerings depending on the applications' needs and the service provider's trustworthiness.
The service provider's and application's Service Level Agreement (SLA) is used to specify which service capabilities and service capability functions the application is allowed to use.
Service capability usage/quality of service
Usage policies can be applied on both service provider and application level. They make it possible to specify differentiated Quality of Service (QoS) offerings for the service providers and their applications.
On service provider level these policies define both a guaranteed and a maximum number of requests an service provider is allowed to send through a specific service capability during a specified time period.
On application level these policies define the maximum number of active sessions or maximum number of requests as well as a guaranteed number of requests an application is allowed to send through the service capability during a specified time period.
Network protection and access Control
Access control
Service requests from the applications are given access to individual network nodes depending on the service provider owning the application.
It is possible to maximize the total request rate for a service provider's applications towards individual network nodes.
All service requests from WebLogic Network Gatekeeper to an individual network node can be barred/unbarred through a single operation.
Traffic throttling/overload protection
The maximum request rate from WebLogic Network Gatekeeper towards each individual network nodes can be specified.
For network nodes with the ability to report their current load, WebLogic Network Gatekeeper can dynamically adapt the amount of traffic towards the individual node depending on the node's load status. Two overload levels can be defined:
In the overloaded situation, only traffic from prioritized service providers are let through. If the severely overloaded situation occurs, all request sending towards the node is stopped and the severely overloaded is reported back to the requesting applications.
Node load and delay reduction
It is possible to reduce the load on the underlying nodes through barring excessive send lists. The maximum send list size is configurable on individual node level. Send lists exceeding the specified limit will be rejected. The feature supports the following service capabilities:
Unexpected network initiated event handling
Weblogic Network Gatekeeper handles unsubscribed network initiated events. The following options are available in the call control case:
The following options are available in the messaging case:
Quality of service assurance
Traffic from high priority service providers always have precedence before traffic from low priority service providers to assure the guaranteed amount of traffic.
Other policies areas
Policy is also used in the following areas:
- Charging (for example service provider and application specific service code insertion for rating purposes)
- Subscriber privacy (for example in user location)
Rule based policy execution
At start up, all policy rules are automatically imported to the rule engine's working memory. When policy rules are added or updated, these are imported to the rule engine using the WebLogic Network Gatekeeper Management Tool.
The rule based policies are triggered at Policy Enforcement Points (PEPs). PEPs are implemented in the service capability modules. At the PEPs, a request to use a service capability can be rejected or allowed. The decision whether the request should be rejected or allowed is taken by the Policy Decision Point (PDP) in the rules engine. To take the policy decision, the PDP needs the request data and the rule associated with the PEP. The policy is then enforced at the PEP. An overview is shown in Figure 7-1, Policy execution flow for application initiated request, on page 7-5.
Basic request data is always provided by the PEP. Additional data needed for the rule engine's decision can be provided by the SLA database, the SLEE database, and/or from other external databases.
Together, the data and the rules make it possible for the PDP to take a policy decision. The decision is used by the PEP and the request is rejected or allowed depending on the decision. In addition, the PDP can modify the incoming request data or add new data based on the rules used. The new or modified data is returned to the PEP together with the policy decision.
Plug-in manager policy execution
To peform network protection and network access control, the Policy Enforcement Point (PEP) in the plug-in manager is used.
The policy execution flow through the plug-in manager is shown in Figure 7-2, WebLogic Network Gatekeeper policy execution flow in an application initiated service request flow, on page 7-7.
Below follows a description of the most important steps in the policy execution flow shown in Figure 7-2, WebLogic Network Gatekeeper policy execution flow in an application initiated service request flow, on page 7-7.
- The plug-in manager retrieves a list of possible plug-ins based on the address plan and destination address indicated in the service request.
- The plug-in manager sends the list of possible plug-ins and the service request data to the rule engine for a policy decision. The rule engine makes a policy decision based on the following:
