Prototype Security Gateway Overview
Note: This page documents the legacy, standalone security gateway prototype. For more information about current security gateway development, please see the Security Gateway page.
A security gateway is a solution for enforcing identity and security for SOAP, XML, and REST based web services. It is a dedicated application which allows for a more centralized approach to security and identity enforcement, similar to how a protocol firewall is deployed at the perimeter of a network for centralized access control at the connection and port level.
Why a Security Gateway?
Cloud4all needs a component where security and identity can be enforced. Specifically, we need a component where users can be authorized and get his preferences when a concrete application, device or network wants to use these preferences, in a specific moment or context.
Mike wants to use Easit4all to access to his social networks. He is a Cloud4all user and already has a set of preferences. He has a set of security policies defining from what application he can get his policies and from what network. He logs in the application, an authorized application from his home (an authorized network). Easit4all sends the preferences request to the security gateway. There, an XACML request is generated and evaluated, based on the information provided by the request. The Gateway permits the request and forwards the request to the endpoint, this is the Preferences Server. At the end, the Easit4all gets the Mike's policies.
Cloud4all user at library
Mike has chosen a high security policy option in PMT. that means that when Mike is, for instance, at library with a untrusted device, a message will appear warning the user. In this message the system asks for permission to go forward despite of the risk and load his preferences.
Cloud4all Security Requirements
REQ-ETH-001: Confidentiality towards informants and participants.
REQ-ETH-002: Non-disclosure of sensitive information.
REQ-ETH-003: Treatment of participants as intelligent beings, able to make their own decisions on how the information they provide can be used, shared and made public.
REQ-ETH-004: Treatment of disappointment. It is necessary to clearly establish the function or objectives of the tool to be developed so there is no sense of disappointment.
REQ-ETH-005: Content Reliability.
REQ-ETH-006: The service provided should endorse modern society’s ethical principles, especially those related to equality and rights of people with disability.
[REQ-LEG-001]: Data protection laws and regulations.
[REQ-LEG-002]: Inform users how information and data obtained will be used, processed, shared and disposed of.
[REQ-LEG-003]: Directive 2001/29/EC on copyright – Article 5.3 on exceptions or limitations.
[REQ-LEG-004]: Directive 2002/58 on Privacy and Electronic Communications. The directive obliges the providers of services to erase or anonymize the traffic data processed when no longer needed, unless the conditions from Article 15 have been fulfilled.
[REQ-LEG-005]: Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data.
[REQ-PRI-001]: All sensitive data should be transmitted securely between cloud and user side, as well as, between cloud-cloud components.
[REQ-PRI-002]: All sensitive data should be stored securely.
[REQ-PRI-003]: The system should have an adequate IAM system.
[REQ-PRI-004]: The system should use role-based access control (RBAC).
[REQ-PRI-005]: In a production deployment, digital identities and credentials must be protected with adequate policies.
[REQ-PRI-006]: In a production deployment, the system should collect or produce data about user activity in the cloud.
[REQ-SEC-001]: The system should be protected against DoS/DDoS attacks.
[REQ-SEC-002]: The communication within the system should enable a user to perform basic functions while remaining anonymous, if they desire.
[REQ-SEC-003]: The system shouldn’t allow unauthorized applications to abuse the system.
[REQ-SEC-004]: Data storage should be with data dispersion.
[REQ-SEC-005]: User preferences and administrative user information, such as contracts, passwords should be stored separately in two different components.
[REQ-SEC-006]: In a production deployment, the system should implement protection against phishing, data loss, and malware.
[REQ-SEC-007]: Systems responsible should follow the rule of least privilege when provisioning an account.
[REQ-SEC-008]: In a production deployment, virtual machines should be encrypted when not in use and hardened by default.
[REQ-SEC-009]: Administrative interfaces should be separated from ordinary entry points.
[REQ-SEC-0010]: Thin client (User Listener) and any other application should be protected against malicious use or manipulation of its code.
[REQ-SEC-0011]: Thin client and any other application should be downloaded in a secure way.
[REQ-SEC-0012]: In a production deployment, the system should detail policies and procedures for backup.
[REQ-SEC-0013]: The system should have different levels of identity checks based on the resources required.
[REQ-SEC-0014]: In key management: short key lifetime. Keys should be replaced frequently in order to avoid their compromise.
[REQ-SEC-0015]: Where appropriate, two-factor authentication should be used to manage critical components.
[REQ-SEC-0016]: The system should have the ability to be integrated with single sign-on tools when deployed in appropriate environments.
[REQ-SEC-0017]: The system should classify assets in terms of sensitivity and criticality.
WSO2 is an open source application development software company focused on providing service-oriented architecture (SOA) solutions for professional developers.
WSO2 Carbon is an SOA middleware platform from WSO2. Built on OSGi, Carbon encapsulates major SOA functionality such as data services, business process management, ESB routing/transformation, rules, security, throttling, caching, logging and monitoring. WSO2 products such as Application Server, Enterprise Service Bus, and Business Process Server are built on top of the WSO2 Carbon middleware platform. The WSO2 products are available to download, or can be custom-built by adding the components on top of the Carbon core.
- WSO2 Enterprise Service Bus (ESB): is a simple, lightweight and high performance enterprise service bus (ESB), based on the Apache Synapse enterprise service bus, providing enhanced management and development/configuration support and SOA Governance capabilities. Ebay uses WSO2 Enterprise Service Bus as one of the key elements in its transaction software, which continuously executes $2,000 worth of transactions per second
- WSO Identity Server (IS): is an open source identity & entitlement management server having support for Information Cards, OpenID and XACML.
- WSO2 Business Activity Monitor (BAM): is a Business Activity Monitor designed to monitor and understand business activities within a SOA deployment, which also can be extended to cater for other general monitoring requirements.
Actors and System components:
1 The User: A standard Cloud4all user, with one several disabilities.
2. The Proxy Server: Component responsible for managing all traffic across the gateway. It manages the incoming and outcoming packets, sends data to motinoring system and acts as a policy enforcement point, so it applies the decision of identity server for a specific incoming request.
3. The Identity Server: It is the authorization server. It has a repository of security policies and has a engine to evaluate these policies basen on request form Proxy Server.
4. Activity Monitor: This component collects all information needed for audit purposes from the central point (Proxy Server).
Use Cases diagram
1. To get the prefernces:
- Description: The user wants to recover his preferences from the Preferences Server in the cloud.
- Actors: User, Proxy Server, Identity Server, Preferences Server.
- Preconditions: The user has to have his user preferences in the Preferences Server
- Postconditions: ----
- Main scenario:
The security gateway is composed by 3 elements. The Proxy server, which is the central point of the gateway. The Identity server which acts as a decision point and where all security policies are stored and, finally the Monitoring system, which records all the activity for log and audit purposes.
1. Proxy Server: Proxy server is based on the WSO2 Enterprise Service Bus (WSO ESB). All trafic will cross this component. It permits the development of custom proxies in order to apply a set of processes on traffic crossing across. Therefore, it permits to ask for authorization to other component and, at the same, time send data to a monitoring system.
2. Identity Server: The Identity server is based on the WSO2 Identity Server (WSO IS). It is a Policy Descicion Point (PDP), so where, based on a request, authorization decisions are made. So, it has a repository of all security policies and where these policies are evaluated.
3. Motitoring system: This component also based on WSO2 Business Activity Monitor (WSO2 BAM) is responsible of record all relevant data crossing the gateway.
Security policies are defined with XACML. XACML (eXtensible Access Control Markup Language) defines a declarative access control policy language implemented in XML and a processing model describing how to evaluate access requests according to the rules defined in policies.
XACML policies can have several rules for different purposes. Basically, all rules have 4 attributes.
1. The Resource: It is the resource or service which we have to protect the access. In our case the "Preferences Server".
2. The Action: What we want to do over the resource. In our case we want to "read" the user preferences.
3. The Subject: It is the entity which wants to get the data. In our case the "user token".
4. The Environment: This is a set of aditional customizable atributes. We have created 2 new attributes, the Application ID, and the Origin IP. We could add another one, the device type or device ID.
With all this parameters the gateway will decide if the request is permitted or denied.
We can scale the security gateway in two different ways, interally or externally.
- Internally: We can replicate one or serveral internal components, such as the IS, depending on the performance of each one.
- External: We can replicate the entire gateway, using a load balancing module.
Not authorized Message in EAsit4all application:
Deployment Documentation (step by step)
- D104.3. Security, privacy and ethical policy assurance Gateway: A very brief (a few pages) written description, indicating the basic functionalities and the possible current implementation limitations. (File:D104.3. Security, privacy and ethical policy assurance Gateway.pdf)
- Deloyment guide: Explanation step by step how to deploy the security gateway. (File:Security Gateway delpoyment step by step.pdf)
Ideas for the future
This sections shows several ideas to improve the overall security in Cloud4all architecture in a near future.
User Token Generation:
The user token is always the same, so always users send the same token through the net. We could find a way to generate a One Time Token, merging a one time passcode each time that the user requests their preferences.
Security in mobile platforms:
In mobile platforms we could use the Security Element (SE). The Secure Element is a tamper resistant device with an embedded microprocessor chip. A platform where applications can be installed, personalized and managed.
Authorization, granularity of the consent: