ETSI GS INS 001 V1.1.1 (2011-03)

Identity and access management for Networks and Services; IdM Interoperability between Operators or ISPs with Enterprise

DGS/INS-001

General Information

• Status: Published
• Publication Date: 28-Feb-2011
• Technical Committee: INS - Identity and access management for Networks and Services
• Current Stage: 12 - Completion
• Due Date: 02-Mar-2011
• Completion Date: 01-Mar-2011

Standards Content (Sample)

Group Specification
Identity and access management for Networks and Services;
IdM Interoperability between Operators or
ISPs with Enterprise
Disclaimer
This document has been produced and approved by the Identity and Access Management for Networks and Services
(ETSI INS) ETSI Industry Specification Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

2 ETSI GS INS 001 V1.1.1 (2011-03)

Reference
DGS/INS-001
Keywords
access, ID, interoperability, management,
network, service, use case
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2011.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
LTE™ is a Trade Mark of ETSI currently being registered
for the benefit of its Members and of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI GS INS 001 V1.1.1 (2011-03)
Contents
Intellectual Property Rights . 5
Foreword . 5
Introduction . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Abbreviations . 7
4 IdM Overview: authentication and attribute exchange. 7
4.1 Operators/ISPs . 7
4.1.1 Authentication . 7
4.1.2 Attribute Exchange . 8
4.2 Enterprise (and Home Network) . 9
4.2.1 Authentication . 9
4.2.2 Attribute Exchange . 10
5 Operator/ISP-Enterprise Use Cases . 10
5.1 SSO for small enterprises and home network users . 10
5.1.1 Description . 10
5.1.2 Actors . 10
5.1.2.1 Actors specific Issues . 10
5.1.2.2 Actors specific benefits . 11
5.1.3 Pre-Condition . 11
5.1.4 Post-Condition . 11
5.1.5 Normative Flow . 12
5.2 Attribute Sharing between Operator and Web Enterprise . 12
5.2.1 Description . 12
5.2.2 Actors . 12
5.2.2.1 Actors specific Issues . 13
5.2.2.2 Actors specific benefits . 13
5.2.3 Pre-Condition . 13
5.2.4 Post-Condition . 13
5.2.5 Normative Flow . 14
5.3 Outsource billing to operator . 14
5.3.1 Description . 14
5.3.2 Actors . 14
5.3.2.1 Actors specific Issues . 15
5.3.2.2 Actors specific benefits . 15
5.3.3 Pre-Condition . 15
5.3.4 Post-Condition . 15
5.3.5 Normative Flow . 16
5.4 Integration of XaaS and multi-stage IdM systems . 17
5.4.1 Description . 17
5.4.2 Actors . 17
5.4.2.1 Actors specific Issues . 17
5.4.2.2 Actors specific benefits . 18
5.4.3 Pre-Conditions . 18
5.4.4 Post-Condition . 18
5.4.5 Example Flow . 19
5.5 Authentication as a service . 20
5.5.1 Description . 20
5.5.2 Actors . 20
5.5.2.1 Actors Specific Issues . 20
5.5.2.2 Actor Specific Benefits . 21
ETSI
4 ETSI GS INS 001 V1.1.1 (2011-03)
5.5.3 Pre-conditions . 21
5.5.4 Post-conditions . 21
5.5.5 Example Flow . 22
5.6 Summary Table of Use Cases. 22
6 Functional requirements . 23
7 Functional Requirements: Impact on current architectures . 23
8 Functional architecture definition . 24
8.1 General . 24
8.1.1 Authentication relationship . 25
8.1.2 Attribute exchange relationship . 26
8.1.3 Functional elements description . 27
8.1.3.1 Identity Provider . 27
8.1.3.2 Attribute Provider . 27
8.1.3.3 Authorization Authority . 27
8.1.3.3.1 Authorization Enforcement . 27
8.1.3.3.2 Authorization Validation/Decision . 28
8.1.3.4 Authentication Authority . 28
8.1.3.4.1 Authentication Enforcement . 28
8.1.3.4.2 Authentication Validation/Decision . 28
8.1.3.5 Charging Provider . 28
8.1.3.6 Identity Provisioning . 29
8.1.3.7 Identity Broker . 29
8.2 Interfaces . 29
8.2.1.1 IdentityResolution . 29
8.2.1.2 IdentityManagement . 30
8.2.1.3 AttributeManagement . 30
8.2.1.4 IdentityAuthentication . 31
8.2.2 IdentityCharging interface . 32
8.3 Protocols . 32
8.3.1 Interface c . 32
8.3.2 Interface d . 32
8.3.3 Interface e1 . 32
8.3.4 Interface e2 . 32
9 Operator/ISP-Enterprise IdM Interoperability instantiation . 33
9.1 Instantiation SSO for small enterprises and home network users . 33
9.1.1 Instantiation Video On Demand System . 33
9.1.2 Instantiation Local IdM (e.g. Home or Enterprise IdM) . 33
9.1.3 Instantiation Operator IdM . 33
9.1.4 Use of Interfaces . 33
9.2 Instantiation Authentication as a Service . 34
9.2.1 Instantiation Enterprise . 34
9.2.2 Instantiation Mobile Operator . 35
9.2.3 Use of Interfaces . 36
Annex A (informative): Authors and contributors . 37
History . 38

ETSI
5 ETSI GS INS 001 V1.1.1 (2011-03)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Group Specification (GS) has been produced by ETSI Industry Specification (ISG) Identity and access
management for Networks and Services (INS).
Introduction
In the present document we present an architecture and its instantiation for use cases where interoperability exists
between Operators and Enterprises in terms of authentication and attribute exchange. Historically both domains were
seen as separated, without any kind of interactions. The demand for new scenarios, i.e. Software as a Service, implies
that some interactions need to be in place. This cooperation can be achieved either by exchanging data about the user or
reusing the authentication context.
The first part of the present document provides a brief overview of the actual authentication and attributes exchange
within the Operator and the Enterprise. Next, a set of use cases which demand for cooperation between Enterprise and
Operators are presented. These use cases are the ground to collect the requirements and the impact of such requirements
in the actual architectures.
The second part of the present document presents the architecture in terms of functions and its relationships, which
answers the collected requirements. Moreover it describes the interfaces and the protocols such interfaces can use.
Finally two examples of its instantiation are presented.
ETSI
6 ETSI GS INS 001 V1.1.1 (2011-03)
1 Scope
The present document presents a set of use-cases where the interoperability between Operators and Enterprise allows
authentication reuse and attributes exchange. It identifies and describes the requirements imposed by such scenarios,
derives an architecture and describes a set of interfaces or operations between architectural elements.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are necessary for the application of the present document.
Not applicable.
2.2 Informative references
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] Cantor, S., Kemp, J., Philpott, R., and Maler, E.: "Assertions and Protocols for the OASIS Security
Assertion Markup Language (SAML) V2.0". March 2005.
NOTE: Available at http://docs.oasis-open.org/security/saml/v2.0/.
[i.2] OpenID Foundation.
NOTE: Available at http://openid.net/.
[i.3] S. Cantor, J. Kemp, and D. Champagne (editors): "Liberty ID-FF bindings and profiles
specification --- 1.2-errata-v2.0, 2004. Liberty Alliance Project".
[i.4] S. Cantor, J. Kemp, R. Philpott and E. Maler (editors): "Assertions and Protocols for the OASIS
Security Assertion Markup Language (SAML) V2.0", OASIS - December 2009.
[i.5] S. Cantor, J. Kemp, R. Philpott, E. Maler and P. Mishra (editors): "Authentication Context for the
OASIS Security Assertion Markup Language (SAML) V2.0", OASIS - March 2005.
[i.6] S. Cantor, J. Kemp, R. Philpott, E. Maler and F. Hirsch (editors): "Bindings for the OASIS
Security Assertion Markup Language (SAML) V2.0", OASIS - March 2005.
[i.7] J. Hughes, S. Cantor, J. Hodges, P. Mishra, R. Philpott, E. Maler and F. Hirsch (editors): "Profiles
for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS - December 2009.
[i.8] S. Cantor, J. Moreh, R. Phipott and E. Maler (editors): "Metadata for the OASIS Security
Assertion Markup Language (SAML) V2.0", OASIS - December 2009.
[i.9] F. Hirsch, R. Philpott and E. Maler (editors): "Security and Privacy Considerations for the OASIS
Security Assertion Markup Language (SAML) V2.0", OASIS - March 2005.
ETSI
7 ETSI GS INS 001 V1.1.1 (2011-03)
[i.10] P. Mishra, R. Philpott and E. Maler (editors): "Conformance Requirements for the OASIS Security
Assertion Markup Language (SAML) V2.0", OASIS - March 2005.
[i.11] J. Hodges, R. Philpott and E. Maler (editors): "Glossary for the OASIS Security Assertion Markup
Language (SAML) V2.0", OASIS - March 2005.
3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AAA Authentication Authorization and Accounting
AAAS Authentication, Authorization and Accounting Server
AKA Authentication and Key Agreement
CPE Customer Premises Equipment
DB DataBase
DHP Data Handling Policy
GSM Global System for Mobile Communications
HSS Home Subscriber Server
HTTP Hypertext Transfer Protocol
ID IDentity
IdM Identity Management
IdP Identity Provider
IMSI International Mobile Subscriber Identity
ISP Internet Service Provider
LDAP Lightweight Directory Access Protocol
ME Mobile Equipment
MO Mobile Operator
NAS Network Access Server
PKI Public Key Infrastructure
PW Password
QoS Quality of Service
SaaS Software as a Service
SAML Security Assertion Markup Language
SIM Subscriber Identity Module
SP Service Provider
SSO Single Sign-On
U(SIM) Universal Subscriber Identity Module
UE User Equipment
USB Universal Serial Bus
VoD Video on Demand
VPN Virtual Private Network
w.r.t. with respect to
WS Web Service
XaaS X as a Service
4 IdM Overview: authentication and attribute exchange
4.1 Operators/ISPs
This clause briefly describes the authentication and attributes exchange mechanisms and architecture for an operator.
ETSI
8 ETSI GS INS 001 V1.1.1 (2011-03)
4.1.1 Authentication
Authentication defines the process where one entity (commonly named server) verifies another entity's claim to holding
a specific digital identity (commonly named client). Authentication is accomplished using two different processes:
i) Implicit authentication (device authentication) - relies only on an implicit authentication through physical or
logical identity on the layer 2 transport layer.
ii) Explicit authentication (user authentication) - relies on an explicit signaling between the client (UE) and the
authentication server. The UE sends its corresponding credentials to the server where they must be validated.
Different types of credentials could be used. Examples are passwords, digital certificates, or one-time tokens.
The network registration involves the authentication and authorization procedures between a client (UE) and the server
which controls the access to the access network based on the credentials the UE sent and the policies.
In order to provide interoperability between various network equipments, protocols for various segments of the
authentication model have been standardized.
Figure 1 provides an abstract architecture for the typically network authentication mechanisms.

Figure 1: Network authentication abstract architecture
The architecture is composed by different entities, presented next:
1) User Equipment (UE) - represents the entity which needs to be authenticated, during the network registration.
The result of a successful authentication procedure results in network access.
2) Network Access Server (NAS) - This entity translates the network access requests issued by the UE and
forwards it to the AAA (Authentication, Authorization and Accounting) Server.
3) AAA Server - represents the server which performs the user authentication and authorization for network
access. This entity retrieves authentication data from a database that could, or not, be collocated with the AAA
server. After a successfully authentication the AAA server produces a set of authorization rules that are
enforced in the NAS entity. Those rules are typically, operator's defined and stored in the Attributes Database
(DB).
4) AAA Proxy - the AAA Proxy is a typical AAA server which acts as a proxy for the user's requests. Upon the
reception of user's requests it forwards them to the AAA server in charge of the authentication procedure. The
AAA server location is one of the AAA proxy functionalities. Responses received back from the AAA server
will be returned to the NAS.
5) Attributes DB - this entity contains the user authentication data (user identity, key materials, etc.). It could also
contain information related with operator's authorization and accounting rules, as well as user specific
configuration data. Dynamic information related with the user is also maintained in this DB. An example is the
user's location in moment he authenticates and accesses the network.
4.1.2 Attribute Exchange
One of the components in an operator infrastructure is the Attribute Database (see figure 1). This entity stores static
information provisioned by the operator. An example of such information is the user's profile. On the other hand, more
dynamic information could also be stored, e.g. user's location. Both types of information can be exchanged with other
network entities through interfaces "a" and "b".
ETSI
9 ETSI GS INS 001 V1.1.1 (2011-03)
Interface "a" is used during the network registration process for different proposes:
i) transport the necessary information for the authentication procedure;
ii) transport the user's profile (or part of it) to the NAS. The goal of such action is to provide NAS with the
necessary information to correctly configure the filters (e.g. QoS, or firewall) that will support the entrance of
the new user. That information is stored in the Attributes DB;
iii) Provide user's dynamic information to the AAA server (in fact that information will populate the Attributes
DB, that could or not be co-located with the AAA server). Example of such information is user's context
information.
Another interface, "b", exists that provides a way for Application to retrieve information, related with the user that it is
stored in the Attribute DB. The use of this interface is not limited to any of the two information types stored within the
Attributes DB. It is possible to retrieve user's profile (static) information or user's generated information (e.g. context
information). The attributes collected from the Attributes DB will feed operator's internal or external applications.
The exchange of the information between the Attributes DB and the appropriate counterpart are based on established
standard protocols.
4.2 Enterprise (and Home Network)
This clause describes the common technology used for authentication and attribute exchange in the Internet Services
domain, the Enterprise and home networks belong to. From a network layer point of view, the Internet Services reside
in the application layer, this is a higher layer than the basic network authentication mentioned in the previous clause.
4.2.1 Authentication
Authentication information in the internet services of the user domain can be transferred by different protocols
(e.g. SAML [i.1], OpenID [i.2], ID-FF [i.3]). The most common authentication protocol in the Enterprise is SAML.
The fundamental SAML architecture consists of:
• a User (subject in SAML terms), who wishes access to a certain resource or service;
• a Service Provider, who provides the desired resource or service; and
• an Identity Provider, providing application layer authentication of the User (e.g. based on additional
authentication providers in other layers) and issues assertions about Users to Service Providers. It plays a key
role in federating identities.
The SAML architecture can easily be mapped to the Operator/ISP - Enterprise interworking setting. The result of this
mapping is shown in figure 2, in which interface 'd' is for example instantiated with the SAML protocol. A conceptual
difference is that in SAML a subject (user) can have several Identifiers of different type (NameID-Type) that will
depend on the authentication (service) context.
ETSI
10 ETSI GS INS 001 V1.1.1 (2011-03)

Figure 2: Service Provider abstract architecture
The current SAML version 2.0 consists of the following specifications, all of which are available on [i.4]. Table 1
summarizes the several SAML specifications.
Table 1: SAML core specification summary
Specification Summary
Core [i.4] XML schemas for assertions and SAML request-response
protocols
Authentication Context [i.5] Includes the actual authentication method used (eg,
Password, Smartcard, Kerberos)
Bindings [i.6] Define how SAML request-response messages can be
mapped onto standard messaging protocols such as HTTP
or SOAP
Profiles [i.7] Define rules for using and restricting SAML's syntax for
conveying security information to solve specific business
problems (eg, web SSO exchange)
Metadata [i.8] Defines how a SAML entity can describe its configuration
data (e.g. service endpoint URLs, key material for verifying
signatures) in a standard way for consumption by partner
entities
Security and privacy considerations [i.9] Security and privacy considerations w.r.t. security
techniques, bindings, profiles
Conformance [i.10] Describes features that are mandatory and optional for
implementations claiming conformance to SAML
Glossary [i.11] Defines terms used throughout SAML specifications and
related documents
4.2.2 Attribute Exchange
Attribute exchange works similar to authentication and is defined in the Core SAML specification [i.1].
ETSI
11 ETSI GS INS 001 V1.1.1 (2011-03)
5 Operator/ISP-Enterprise Use Cases
5.1 SSO for small enterprises and home network users
5.1.1 Description
The user from his enterprise or home network wants to login to a SP.
5.1.2 Actors
• User.
• Operator/ISP IDP.
• Home IDP.
• SP.
5.1.2.1 Actors specific Issues
• User:
- Wants to utilize his Enterprise SSO for Web Services.
• Operator:
- Provides service of IDP.
• Home IdM:
- Provides support functions (e.g. id mapping, or local authentication) for the operator IDP.
• Web Service:
- Relies on SSO provided by operator.
5.1.2.2 Actors specific benefits
• User:
- Receives a convenient experience of SSO across enterprise and web service.
- Does not need to consider roles and different account names.
• Operator:
- Provides service of IDP.
• Home IdM:
- No direct benefit, but Home IdM is necessary to provide mapping.
• Web Service:
- Benefits by easier accessibility.
5.1.3 Pre-Condition
• The Home IdM has to be registered with the Telco IdM.
ETSI
12 ETSI GS INS 001 V1.1.1 (2011-03)
• The Home IdM can authenticate the user.
• the user has the Telco IdM set as his IDP.
• the SP relies on Telco IDP as SSO authentication source.
5.1.4 Post-Condition
• User is logged in to the web service without performing additional authentication.
5.1.5 Normative Flow
Figure 3: SSO for small enterprises and home network users
Flow description:
1) The user, upon arriving on the web site of the SP, clicks on the "Telco ID" login button.
2) Then the SP queries the Telco IDP for authentication.
3) The Telco IDP identifies that the user is at home, without direct Network Access means of identifying. He
queries the users Home IdM for authentication.
4) The User Home IdM utilizes his own policy to perform authentication and returns a SAML assertion to the
Telco IDP.
5) The Telco IDP provides the SAML assertion about the user identity to the SP.
ETSI
13 ETSI GS INS 001 V1.1.1 (2011-03)
5.2 Attribute Sharing between Operator and Web Enterprise
5.2.1 Description
User requests e.g. a video-on-demand (VoD) provided by a web enterprise over the Internet. He changes his default
screen resolution and likes this value to be used across different web enterprise applications. For this the attribute has to
be stored at the identity provider.
5.2.2 Actors
• User.
• Operator/ISP (IDP).
• Web enterprise (SP).
5.2.2.1 Actors specific Issues
• User:
- Wants to have his default values automatically used by different web enterprise services.
• Operator:
- Provides service of IDP.
• Web Enterprise:
- Provide a service to the customer.
- Utilizes different attributes to customize service.
5.2.2.2 Actors specific benefits
• User:
- Needs to do customization only once.
• Operator:
- Provides service of attribute sharing to different web enterprises.
- Is trusted partner of web enterprise.
• Web Enterprise:
- Can customize service according to needs of user, regardless if first time at service or frequent user.
5.2.3 Pre-Condition
• The operator/ISP has stored User identity attributes such as "screen resolution" (of the User's display on which
the User wants to watch the VoD) and "available bandwidth" (a value that characterizes the bandwidth
available to the User).
• The User wants the operator/ISP to act as IDP on behalf of the User.
5.2.4 Post-Condition
• Attribute of user is stored at IDP by web enterprise.
ETSI
14 ETSI GS INS 001 V1.1.1 (2011-03)
5.2.5 Normative Flow
Figure 4: Attribute Sharing between Operator and Web Enterprise
Flow description:
1) The User requests a video-on-demand (VoD) provided by a web enterprise (SP) over the Internet.
2) The web enterprise asks the operator/ISP for User identity attributes such as "screen resolution" and "available
bandwidth".
3) The operator/ISP sends the values of the requested User identity attributes to the web enterprise.
4) The user performs some changes to his user profile, e.g. update of phone number, or change in layout.
5) The SP pushes a new value of the attribute to the Telco IdM.
6) The Telco IdM stores the new value.
NOTE: There are a lot of variations of this use case if you replace the attributes "screen resolution" and "available
bandwidth" by, e.g. "bank account number", "credit card number", or "email address".
5.3 Outsource billing to operator
5.3.1 Description
The User wants to access a commercial service for which he has to be charged. In this use case the charging element is
outsourced from the Service Provider to the Operator's Identity Provider. An already established legal relation may exist
between the Service Provider and the Operator.
5.3.2 Actors
• User.
• Operator/ISP Identity Provider.
ETSI
15 ETSI GS INS 001 V1.1.1 (2011-03)
• Service Provider.
5.3.2.1 Actors specific Issues
• User:
- Wants to access a service.
- The bill is paid through the Operator/ISP.
• Operator /ISP Identity Provider:
- Has a pre-established contract with the SP.
rd
- Provides outsource billing services to 3 party services providers.
• Service Provider:
- The entity which provides the commercial content to the user.
- Relies on external billing services.
5.3.2.2 Actors specific benefits
• User:
- Receives a service without having a formal contract with the service provider (user's privacy is
enhanced).
- The service is charged directly on the user's account in the operator.
• Operator:
rd
- Provides service of billing to 3 party providers.
• Service Provider:
- Increase of potential users once there is no need to explicit create a contract with the user.
- All the Operators users are potential user's for the service.
5.3.3 Pre-Condition
• A contract exists between the User and the Operator.
• A contract exists between the Operator and the Service Provider.
5.3.4 Post-Condition
• User consumes the service without performing additional registration with the SP.
• Payment is transferred from the Operator to the SP.
ETSI
16 ETSI GS INS 001 V1.1.1 (2011-03)
5.3.5 Normative Flow
A pre-established contract exist
Operator X
Service Provider
IdentityBroker
1. Request to access the service
2. Who is your operator? (choose in the list)
3. Operator X
4. Redirect user to Operator X for authentication
Authentication process
5. User is authenticated. Billing for the service authorized
Access the service
7. Billing information exchange

Figure 5: service access
Flow description:
1) The user requests a certain service form the Service Provider.
2) A list of supported operators are presented to the user.
3) The user chooses his operator (the one he has a pre-established contract).
4) The Service Provider redirects the user to the selected operator, for user authentication.
5) If user's authentication is successful the Service Provider receives a "billing authorization" from the Operator.
6) The User access the service.
7) The Service Provider contacts the Operator in order to receive billing for the transaction.
ETSI
17 ETSI GS INS 001 V1.1.1 (2011-03)
5.4 Integration of XaaS and multi-stage IdM systems
5.4.1 Description
This use case demonstrates how a hierarchical authentication and a hierarchical attributed exchange can be done among
XaaS, which is operated by Operator or ISP, and Enterprise.
An Employee X is going to use XaaS service, where the contract has been signed by Employee X's Company for
enterprise use. To make use of services for Employee X, traditionally XaaS provider has to set up ID/PW for Employee
X but actually XaaS provider does not require authentication of individual user. It only needs to confirm the user is an
Employee at the Employee X's Company. Thus in this user case, Enterprise: Employee X's Company is used for
authentication of Employee X. When Employee X accesses to XaaS service, XaaS provider requires Employee X to
input his company code to identify Enterprise. XaaS provider redirects Employee X to Employee X's Company with
authentication request. After Employee X's Company authenticates Employee X by its own authentication scheme
(e.g. ID/PW, PKI, etc.), it re-redirects Employee X to XaaS service with authentication assertion. XaaS service verifies
the assertion and allows Employee X to use the service. XaaS provider manages identity of Employee X's Company.
Employee X is managed as a virtual identity of Employee X's Company. When XaaS service requires Employee X's
attribute to provide customized service to Employee X, XaaS provider requests attributes to Employee X's Company.
Service Provider Service Provider
Service Provider
V
Applications
e
SaaS SaaS Employee SaaS
r
Another
Layer
t
i
X
c
Enterprise
a
l
F
e
d
Environment
Classic Classic
e
PaaS
r
Layer
a Platform Platform
t
i
o
Employee
n
X’s
Infrastructure
Company
Classic Classic
Layer IaaS
Platform Platform
Platform Provider Infrastructure Provider
Horizontal Federation
Figure 6: Use Case Integration of XaaS and Enterprise system
Figure 6 shows the overview idea of federation among XaaS and Enterprise.
5.4.2 Actors
• Employee X.
• Employee X's Company.
• Operator (XaaS Services Provider).
5.4.2.1 Actors specific Issues
• Employee X:
- Desires XaaS services usage but does not have an account at XaaS provider.
• Employee X's Company:
- Stores data related to their employees.
- Acts and an IdP for its employee's.
ETSI
18 ETSI GS INS 001 V1.1.1 (2011-03)
- Has signed contract of XaaS services.
• Operator (XaaS Services Provider):
- Maintains and operates the XaaS infrastructure and services.
- Has a trust relation with Employee X's company.
- Acts as a service provider (regarding the authentication request and attribute request to the Company).
5.4.2.2 Actors specific benefits
• Employee X:
- Does not need to have and remember another ID/PW for the usage of XaaS services.
• Employee X's Company:
- Maintains control over employee authentication and attributes provision.
- Can provide XaaS service usage to any employee with a single agreement with the Operator, which
offers XaaS services.
• Operator:
- Can provide various XaaS services to several Companies.
- Does not have to manage users' credentials or attributes.
5.4.3 Pre-Conditions
• Employee X's Company and Operator, which is providing XaaS services, have already agreed and signed the
contract.
• Employee X is registered as an Employee at Identity Management system at Employee X's Company.
5.4.4 Post-Condition
• In addition to authentication and attribute provision, access control can also be forced at Employee X's
Company.
• Operator might customize its XaaS service based on user's attributes, which is retrieved from Employee X's
Company.
ETSI
19 ETSI GS INS 001 V1.1.1 (2011-03)
5.4.5 Example Flow
Business Agreement on SaaS service usage
Information on
Information on
Em ployee X’s
Employees
Company
Operator
Employee
(SaaS service)
X’s Company
1. Requests usage of a service
2. Asks for entering company id
3. Enters company id
4. Check endpoint URL
of
...