This chapter explains the tasks required to implement Oracle Communications Services Gatekeeper securely.
The communication services that your partners provide generally require both authentication and authorization services to remain secure. You can provide this security in several ways:
The Services Gatekeeper security provider authenticates subscribers by verifying their application's IDs and passwords.
The Services Gatekeeper service-level agreements (SLAs) provide authorization. You secure communication services by authorizing service requests with SLAs, and by authenticating users making the requests with web services security. This is true for services created by you or your partners. SLAs can define the API and TPS that the application can use. For more information, see:
OAuth provides both authorization and SSO authentication for third-party resources. See "Authenticating and Authorizing Resources with OAuth" for more information.
You can use Security Assertion Markup Language (SAML) credentials to gain access to resources protected by OAuth 2.0 in Services Gatekeeper. Services. This enables you to create single sign on (SSO) features that provide your subscribers with one authorized SAML token (federated identity) for use in accessing multiple third-party resources. See ”Support for SAML Assertions” in Services Gatekeeper OAuth Guide.
Communication services do not have security enabled by default because Services Gatekeeper has no way of knowing what kind of security they allow. Ensure that you add or take advantage of the communication service's security measures before allowing subscribers to use them.
Services Gatekeeper supports these types of communication services:
SOAP-based
RESTful
Native
For information about securing these communication services, see "About Services Gatekeeper Communication Security” in Services Gatekeeper System Administrator's Guide.
The first step in protecting your SOAP communication services is to ensure that all communication with Services Gatekeeper happens within a session. You set this in the Services Gatekeeper Session Manager Web Service, and it automatically requires applications to provide authorization.
Applications communicating with Services Gatekeeper that use a SOAP interface have these options for authentication:
User name/password authentication (user name token)
Digital signatures (X.509 certificate token)
Encryption (SAML token)
Session IDs
For information about creating and securing a SOAP-based communication service, see the following in Services Gatekeeper Application Developer's Guide:
The RESTful service interfaces use HTTP basic authentication and session IDs for security.
For information about:
Implementing HTTP security, see ”About Services Gatekeeper Communication Security” in Services Gatekeeper System Administrator's Guide.
Creating and securing RESTful communication services, see ”Using the RESTful Interfaces” in Services Gatekeeper Application Developer's Guide.
Requiring sessions for all RESTful communication, see ”Managing Communication Sessions” in Services Gatekeeper Application Developer's Guide.
Services Gatekeeper supports communication services using the MM7, SMPP, and UCP protocols. The following shows security considerations for each protocol:
Native MM7 Communication Services
Services Gatekeeper uses HTTP basic authentication to secure native MM7 communication services. For more information, see ”Native MM7” in Services Gatekeeper Communication Service Reference Guide.
Native SMPP Communication Services
Services Gatekeeper uses authentication credentials to secure native SMPP communication services. For information about creating a native SMPP communications service, see ”Native SMPP” in Services Gatekeeper Communication Service Reference Guide.
Native UCP Communication Services
Services Gatekeeper uses a credential store to secure native UCP communication services. For information about configuring connection information and the credential map, see ”Managing and Configuring Native UCP Connections” in Services Gatekeeper System Administrator's Guide.
Your partners create Service Level Agreements (SLAs) to define who is authorized to use their services. Every communication service must have an SLA that specifies access privileges to Services Gatekeeper and the network nodes it communicates with.
For more information, see Services Gatekeeper Portal Developer's Guide.
OAuth provides both authorization and authentication services and replaces more traditional SSO mechanisms. For information about using the OAuth protocol to grant access to resources (such as photos, video, and so on) without compromising the resource owner's security, see:
Services Gatekeeper includes tools that monitor the number of transactions that Services Gatekeeper is processing. You use these tools to calculate usage and group reports, but they can also be valuable tools for alerting you of denial of service (DOS) attacks. For more information, see ”Managing and Configuring Statistics and Transaction Licenses” in Services Gatekeeper System Administrator's Guide.
Services Gatekeeper provides a mechanism that alerts you to impending system overload using the Oracle WebLogic Overload Alarms feature.
Regular backups are an essential part of a secure Services Gatekeeper implementation. You must configure secure ways to handle the following:
Redundancy and failover for clustered services
Automatic restart for managed servers
Managed server independence mode
Automatic migration of failed managed servers
Backing up the domain configuration
Restarting a failed administration server
Restarting failed access and network tier servers
Moving an access or network tier server to a different system.
For more information, see ”Managing, Backing Up, and Restoring Services Gatekeeper” in Services Gatekeeper System Administrator's Guide.
If you are the system administrator for Services Gatekeeper, consider the security associated with configuring and managing the following:
Filtering Tunneled Parameters
Securing SOAP-Based Web Services with Web Services Security (WS-Security)
Securing RESTful Web Services with SSL
Securing Network-Facing Servers With Keystores
Securing the Oracle Access Manager MBeans
For more information, see ”Securing Services Gatekeeper” in Services Gatekeeper System Administrator's Guide.
Configuring tunneling for a communication service can serve as a ”white list” or ”black list” that filters parameters. A while list limits communication service messages to only the parameters that you specify (nothing is limited by default). A black list is a list of just the prohibited messages. White lists especially can be quite restrictive and impractical for most communication, but may fit into your security needs. For information about implementing tunneling, see ”Using Parameter Tunneling” in Services Gatekeeper Extension Developer's Guide.
Your partners use the Partner Manager Portal application to add their services to Services Gatekeeper and to include the network service interfaces created by their network service suppliers. Network service suppliers use the Network Service Supplier application to create the network services interfaces. Partner managers publish or expose these services as APIs. Your partners use the Partner Portal application to create applications with these APIs.
All three roles require secure access control. When partners and network service suppliers log in, the application asks them security questions to obtain the access privilege and authentication with secure passwords. For example, partners are assigned one of the service provider interfaces created for them. These interfaces are administrative user types and must be managed like other administrative users and only granted the access privileges they require.
Configure the required security setup to monitor the accounts being created to ensure that they are legitimate and allowed access to the Partner Portal, Network Services Supplier, and Partner Manager Portal applications. Ensure that the granting, monitoring, and revoking service access is a secure process and takes into account whether the users are internal or external to your organization. For more information, see ”Service Provider Interfaces” in Services Gatekeeper Portal Developer's Guide.
Your service providers use Partner Portal to administer their partner accounts, including granting and revoking service access. The service providers may be internal or external to your organization. Set up Partner Portal and Partner Manager Portal with the security appropriate for your implementation.
Make sure you educate your service providers to:
Enable security for communication services.
Use the secure interfaces supplied with Services Gatekeeper to communicate with Services Gatekeeper.
Use OAuth to manage access to secured resources (such as pictures or secured URLs).
Record their Partner Portal credentials somewhere safe.
Change their automatically generated application IDs as soon as possible because they are predictable.
For more information, see Services Gatekeeper Portal Developer's Guide.