Whenever Cloud services (or Microservices) migrate to a Cloud hosting, they have to adapt their security infrastructures for the target hosting environment (so that users of this environment can authenticate with SSO). In addition, Cloud services need to establish trusts with their partner service providers on demand. Solution: * Describe the security topology of the Cloud application with TOSCA and let the Cloud provider provision the security infrastructure to protect the application on demand. * Describe the capability and requirements of the security topolicy in TOSCA so that the TOSCA engine can match the requirements (of two services) and establish a (direct or indirect) trust between them on demand. More details in publication: http://ieeexplore.ieee.org/document/8114463/

1. How to adapt Authentication & Authorization
Infrastructure of applications for the Cloud
Tri Hoang Vo
Cloud Architect, Deutsche Telekom
FiCloud2017, 21.08.2017
On behalf of
Prof. Dr. Woldemar Fuhrmann, Darmstadt University of Applied Sciences
Dr. Klaus-Peter Fischer-Hellmann, Digamma GmbH

2. 1. introduction
federated identity management (FIDM)
• In FIDM, user attributes from one domain are propagated to another domain for SSO, authorization,
customizing service, logging, and auditing.
 Reduce the cost for SP (no longer manage users that are not under their control).
• Traditional approach: developers adapt Authentication & Authorization Infrastructure (AAI) manually.
21.08.2017Tri Hoang Vo / Identity As A Service 2

3. 1. introduction
FIDM in the Cloud
21.08.2017Tri Hoang Vo / Identity As A Service 3
In the Cloud environment:
• Cloud services adapt to an IDM of a Cloud provider (for user SSO).
• Cloud services integrate with each other on demand.
Problems:
• At the beginning they may adapt AAI manually.
• Frequent provisioning/deprovisioning of Cloud services  dynamic adaptation.
• Users access Cloud services in various security domains  user privacy.

4. 2. idaas
related work
21.08.2017Tri Hoang Vo / Identity As A Service 4
Cloud services need to develop:
• Highly secure & flexible access control mechanisms for identity federation.
• However, this is not a core competency.
 They may prefer to outsource AAI to a third party & focus on developing business functionalities.
 In the past, 4 levels to outsource AAI.
 Onelogin, PingIdentity: provides AAI framework, Cloud services manually adapted for SSO.
• We proposed the 5th level.

5. 3. idaas
proposed model
21.08.2017Tri Hoang Vo / Identity As A Service 5
• We consider application components are unprotected.
• Cloud provider provision AAI to protect application components.
• Application admins control the AAI lifecycle (provisioning, integration update, termination).
• To support, a security architect describes the security topology of his application:
 In a platform-independent AAI model.
 What needed to be preserved across different Cloud providers.
• An orchestration engine reads security topology and provision AAI accordingly.
 A platform-depedent AAI implementation.

6. 3. Security topology
security components
21.08.2017Tri Hoang Vo / Identity As A Service 6
• Security topology describes security component and the relationship with the application backend.
• Security architect of SP specifies how he wants to protect an application APIs in the backend:
 Using an intercepting web agent (same container)
 Using a security gateway (proxy)

7. 3. Security topology
capabilities
21.08.2017Tri Hoang Vo / Identity As A Service 7
• Service consumers may or may not propagate the user identity to a SP.
• Security architect of SC specifies which capabilities his outgoing Proxy offer for identity propagation.
• We collected design patterns for identity propagation between services:
Identity impersonation Identity forwarding Identity delegation

8. 3. Security topology
requirements
21.08.2017Tri Hoang Vo / Identity As A Service 8
• SP requires controlling access to their services.
• Security architect of SP specifies requirements for a service consumer to access resources.
• We collected authorization design patterns:
Trusted Subsystem (direct trust)
 Client calls server with its service id
Delegated access control
 Client calls server with original caller identity

9. 4. AAI Life cycle example
1. Topology modelling (USE TOSCA metamodel)
21.08.2017Tri Hoang Vo / Identity As A Service 9
Security architect (shipping service) describes the security topology as part of the application topology
I want to protect my shipping
service APIs with an Intercepting
Web Agent. The agent must
forward an email address from
the user to the web application.
I trust my partner service
consumer as a Trusted
Subsystem.

10. 4. Aai life cycle example
2. provisioning
21.08.2017Hoang Tri Vo / Identity As A Service 10
Cloud provider provisions AAI components accordingly
Platform & programming language dependent.
e.g.: For JEE application, Cloud provider provisions a ServletFilter that
• intercepts client request & commit user principal
• performs authorization
• forwards user attributes (email address) to the Servlet in the backend

11. 4. Aai life cycle example
3. Integration updates
21.08.2017Hoang Tri Vo / Identity As A Service 11
• When a shopping service signs a contract with the shipping service, orchestrator evaluates
two security topologies if the requirements and capabilities are matched.
• Update the outgoing Proxy of shopping service
 As a Trusted Subsystem for the web agent of shipping service (add truststore).
 Proxy forwards an email address to the web agent (identity forwarding).

12. 4. Aai life cycle example
4. Testing
21.08.2017Tri Hoang Vo / Identity As A Service 12
• Send dummy requests from shopping service to shipping service.
• To test the Trusted Subsystem pattern:
 Shopping service verifies authorization policies (e.g., users with certain roles can access)
 Shipping service verifies that the request is coming from the shopping service & accepts it.

13. 4. Aai life cycle example
5. migration
21.08.2017Tri Hoang Vo / Identity As A Service 13
• Shipping service migrates from Cloud A to Cloud B.
• Cloud B may have a vendor-specific implementation of AAI
 The mutual trust relationship between the two services is provisioned again.

14. 5. Summary & Future work
21.08.2017Tri Hoang Vo / Identity As A Service 14
Summary
• We extended the TOSCA model to describe a security topology of an application.
• The topology describes the security components, capabilities of identity propagation, and
requirements of authorization needed to be preserved across Cloud providers.
• A security architect instantiates a security template and takes advantage of known design patterns.
• Cloud providers provision AAI with its runtime values.
Future work
• User identity is disseminated in federated domains
 Enhance the security topology with privacy-preserving user identity
 Protect confidentiality of disseminated user data.
• Demonstrate in OpenStack