The document discusses Identity-as-a-Service (IDaaS) as a solution for moving enterprise applications between clouds. Traditional identity management requires applications to directly implement identity providers. IDaaS decouples security handling from applications by providing authentication and authorization as a service managed through its lifecycle. IDaaS supports dynamic single sign-on, dynamic service integration, and identity roaming across security domains while protecting user privacy. It is proposed to extend reference architectures like XACML with additional components and to describe application security topologies for provisioning using standards like TOSCA.

1. IDaaS: a missing gap for moving
enterprise applications in Inter-
cloud
Hoang Tri Vo
Cloud Architect, Deutsche Telekom
Frankfurt, 20.07.2016
On behalf of
Prof. Dr. Woldemar Fuhrmann, Darmstadt University of Applied Sciences
Dr. Klaus-Peter Fischer-Hellmann, Digamma GmbH

2. Agenda
Identity-as-a-Service: a missing gap for moving enterprise applications in Inter-Cloud
18.07.2016 2Hoang Tri Vo / Identity As A Service
2. Why moving?
(Motivating scenario)
1. What is a traditional
Identity Management?
3. Definition?
Requirements?
Proposed model?

3. 1. introduction
traditional identity management
Applications trusts an Identity Provider (IdP) for issuing user attributes
• Applications implement security token request / response (SAML, WS-Trust, WS-Federation)
• Mapping attribute assertion issued by IdP to applications
• Applications & IdP exchange trust credentials
18.07.2016Hoang Tri Vo / Identity As A Service 3
One application : n users
• RBAC: access control based on roles of authenticated users
• Access control in implementation codes  only developers can understand
m applications : n users

4. 1. introduction
Attribute based access control (ABAC) [2]
18.07.2016Hoang Tri Vo / Identity As A Service 4
• Access control based on user attributes
• Security policy stored in Policy Decision Point (PDP), controlled by admin at runtime

5. Identity as a service
definition [3]
18.07.2016Hoang Tri Vo / Identity As A Service 5
An approach to identity management in which an entity (individual or organization) relies on special
service provider’s functionalities that allows the entity to perform an electronic transaction, which
requires identity data managed by this provider.

6. 2. Motivating scenarios
dynamic sso
18.07.2016Hoang Tri Vo / Identity As A Service 6
Scenario: an Office service migrates to a (SaaS) Cloud provider
Problems:
• SaaS Cloud provider has existing users who want to use the new Office service.
• Office service has local users who want to use SaaS Storage service.
Traditional solution:
• Cloud provider implements Identity Provider (IdP) for SSO
• Manual adaptation of Office service to IdP

7. 2. Motivating scenarios
dynamic service integration
18.07.2016Hoang Tri Vo / Identity As A Service 7
Scenario:
• In Cloud A, users who use Office service, also use Storage service
• Office service wants to support its users by using Storage service as its service backend
Problems:
• Office service might migrate to Cloud B
• As an Independent Software Vendor (ISV), office service does not want to change its implementation
on any target Cloud platforms

8. 2. Motivating scenarios
identity roaming
18.07.2016Hoang Tri Vo / Identity As A Service 8
Scenario:
• Bob lives in Germany and plays online game (interactive application)
• Bob shortly visits a country in Asia
Problems:
• Application access control (in Asia) requires Bob‘s attributes (in Germany)  200 ms latency
• We need to federate user attributes temporally (from Germany to Asia)
• Problem EU Data Protection Directive: personal information may not be disclosed in another country

9. 3. idaas
requirements
18.07.2016Hoang Tri Vo / Identity As A Service 9
What do we have so far?
• Dynamic SSO between Cloud services and IdP
• Dynamic service integration between Cloud services (frequent provisioning/deprovisioning)
• Identity roaming within federated security domains
Requirements:
We extend „the seventh laws of identity“ of Kim Cameron [4] (for traditional IDM) with:
1. Authentication and Authorization Infrastructure (AAI) as a service
• Decoupling security handling from application logic
• AAI implementation is provided by Cloud provider (Cloud platform specific solution)
• Application admin can control the lifecycle of AAI together with lifecycle of Cloud service
(provisioning, update, termination)
2. Privacy-aware access control for identity roaming

10. 3. idaas
proposed trust model
18.07.2016Hoang Tri Vo / Identity As A Service 10
• Trust establishment should take advantages of exiting trust relationships:
• Users trust their home provider: to provide lawful SPs, to protect user privacy
• SPs trust their home provider: to provide natural users (individuals, organizations)
• Automated trust negotiation between users and an SP in the same local domain as well as between
federated domains is the responsibility of home IDaaS and not of the SPs
• SPs should only concentrate on developing and providing their business services

11. 3. idaas
proposed Components
18.07.2016Hoang Tri Vo / Identity As A Service 11
Reuse the reference architecture of XACML [2] with additional extentions:
• Policy Information Point may be an internal/external service outside a Cloud provider, where users
have billing contracts (e.g., mobile network operators etc).
• Application architects describe AAI (security topology) of the application.
• An orchestration engine reads security topology & controls the life cycle of Policy Enforcement Point
and Policy Decision Point at runtime

12. 4. Future work
security lifecycle management Example
18.07.2016Hoang Tri Vo / Identity As A Service 12
1. Modelling application topology incl. Security components
I want to protect my application APIs. A service can access
the APIs on behalf of a logged-in user. The proxy and the
APIs should be in different hosts
 We may extend TOSCA metamodel (an Open Standard for Topology and Orchestration
Specification for Cloud Applications) for describing security topology of Cloud applications

13. 4. Future work
security lifecycle management Example
18.07.2016Hoang Tri Vo / Identity As A Service 13
2. Provisioning application on a Cloud provider according to the topology description
3. Auto generate integration tests

14. summary
18.07.2016Hoang Tri Vo / Identity As A Service 14
Tradtional IDM IDaaS
SP Provide services for trusted third-party
users (that they do not directly manage)
Outsource IDM to a Cloud provider (to control
its life cycle) due to dynamic provisioning /
deprovisioning of the Cloud application
User Associate user identities from various
SPs with one another
Support user to protect his privacy between
federated security domains

15. References
(1) N. Grozev and R. Buyya, “Inter-Cloud architectures and application brokering: Taxonomy and survey,” Softw. - Pract. Exp., vol. 44, no. 3, pp.
369–390, 2014.
(2) eXtensible Access Control Markup Language (XACML) Version 3.0,” OASIS Standard, 2013. [Online]. Available: http://docs.oasis-
open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html.
(3) “Identity in the Cloud Use Cases Version 1.0,” OASIS Committee Note 01, 2012. [Online]. Available: http://docs.oasis-open.org/id-
cloud/IDCloud-usecases/v1.0/cn01/IDCloud-usecases-v1.0-cn01.html.“
(4) D. Chadwick, “Federated Identity Management,” in Foundations of Security Analysis and Design V SE - 3, vol. 5705, A. Aldini, G. Barthe, and R.
Gorrieri, Eds. Springer Berlin Heidelberg, 2009, pp. 96–120.
(5) “Topology and Orchestration Specification for Cloud Applications,” OASIS, 2013. [Online]. Available: http://docs.oasis-
open.org/tosca/TOSCA/v1.0/cs01/TOSCA-v1.0-cs01.html.
(6) K. Rannenberg, J. Camenisch, and S. Ahmad, Attribute-based Credentials for Trust. Springer, 2015.
18.07.2016 15Tri Hoang Vo/ Identity As A Service