switch edu-id idm market-analysis public · 70 questions and 30 use case descriptions, was sent to...

31
Report Market Analysis of IdM Solutions for Swiss edu-ID Name Surname Job Title Document Type: Report Version: final - public Created: 22.05.16 Last changes: 14.07.16 Classification: Public

Upload: trinhdung

Post on 31-Aug-2018

213 views

Category:

Documents


0 download

TRANSCRIPT

Report Market Analysis of IdM Solutions for Swiss edu-ID

Name Surname Job Title

Document Type: Report Version: final - public Created: 22.05.16 Last changes: 14.07.16 Classification: Public

Classification: Public 2/31

Classification Public

Status Final Version

Project Name Market Analysis IdM Solutions for Swiss edu-ID

Project Acronym Swiss edu-ID IdM RFI

Project Leader Christoph Graf

Project Sponsor SWITCH

Authors Thomas Kessler and Thomas Bühler, TEMET AG

Editors Christoph Graf, Rolf Brugger, Petra Kauer-Ott

Summary

This document contains a market overview of IdM solutions and an assessment of the most suitable products with the potential to fulfil the requirements for the Swiss edu-ID. A confidential version of this document with more details is available for members of the SWITCH community on request from the Swiss edu-ID project members.

Preparation and execution of the RFI by:

Organization Person Function

SWITCH Christoph Graf Project Leader

SWITCH Rolf Brugger Deputy Project Leader

SWITCH Petra Kauer-Ott PMO

Temet Thomas Kessler Architect

Temet Thomas Bühler Consultant

The workshops have been visited by additional members of SWITCH: Christoph Witzig, Andres Aeschlimann, Thomas Lenggenhager, Lukas Hämmerle

Classification: Public 3/31

Content

1 Management Summary 4

2 Introduction 5 2.1 Starting Position 5 2.2 Objective 5 2.3 Scope and Demarcations 6

3 Swiss edu-ID IdM 7 3.1 Goals of Swiss edu-ID 7 3.2 Target Architecture and Scope of Swiss edu-ID IdM 8

4 Sample Use Cases 10

5 Market Analysis (Long List) 15

6 RFI Overview 22 6.1 RFI Timeline 22 6.2 Collected Information 22 6.3 Evaluation Procedure 24 6.4 Evaluation Results 24 6.4.1 Overview 25 6.4.2 Summary of Forced Ranking 26 6.4.3 Overall Assessment of the Shortlist Members 26

7 Conclusion 28 7.1 General conclusion 28 7.2 Pricing 29 7.3 Development 29 7.4 Collaboration 29 7.5 Roadmap Influence 30 7.6 Roadmap Fit 30 7.7 Product Stability and Strategic Relevance 30 7.8 Capital Expenditure and Scalability 30

8 Next Steps 31

Classification: Public 4/31

1 Management Summary

In SWITCHaai, identity management is entirely the responsibility of the organisations participating as identity providers in the federation. With its successor, the Swiss edu-ID, elements of identity management tasks will be performed by SWITCH. The objective of this market analysis is to identify existing identity management products that fit the Swiss edu-ID requirements, to evaluate these products, and to make a recommendation on the next steps in the project.

The RFI was conducted between April and June 2016 in two phases. Firstly, a questionnaire of ca. 70 questions and 30 use case descriptions, was sent to 25 vendors and/or integrators in the field of identity management products and services. In a second step, representatives of the four top-rated products were invited to present and discuss their solution concept at individual workshops.

The questionnaire analysis yielded the following main findings:

1. Most products primarily address a corporate environment. The business to customer scenario of the Swiss edu-ID is supported to a lesser extent. It is therefore unsurprising that off-the-shelf products provide only partial coverage of our requirements.

2. The evaluated products follow different integration approaches. Some products provide a flexible customization architecture which effectively reduces the required development effort. Other products are less customisable and need to be extended through programming. Exten-sions require APIs; these are available and mostly well documented.

3. Independently of how a product is integrated, the know-how and experience required is considerable and hence a big investment has to be made by the customer.

4. Vendors provide different perspectives in terms of a sustainable cooperation model. Some are going through consolidation phases, others tend to bind the customer to the integrator, and some are better prepared for more independent customers with appropriately skilled staff.

5. The license models of all closed source products are based on a per-user scheme, regardless of their respective activity level. As the Swiss edu-ID project expects significant numbers of inactive accounts, either a flat rate or a licensing model clearly distinguishing between active and inactive accounts is required.

6. Commercial products dominate the market. Only a few open-source products are available.

The outcome of the product evaluation workshops was that there is no clear single winning product identified. The evaluation team has agreed to further investigate the product Apache Syncope together with the integrator and main contributor Tirasa. Apache Syncope provides a well developed and configurable workflow engine as well as a documented API for extensions. It allows starting in a small configuration that can be gradually extended over time. The cooperation model is promising, and with appropriate commitment by SWITCH, the product roadmap could be influenced which would also help securing investments. However, the fact that the community and the company for professional services are relatively small poses a risk.

The evaluation team recommends to build a clearly scoped prototype based on Apache Syncope that implements the functions of the currently operational Swiss edu-ID infrastructure and a number of additional use cases. If the product is not suitable for the future Swiss edu-ID service, the competing short-list products or an alternative open-source product will have to be reconsidered.

Classification: Public 5/31

2 Introduction

2.1 Starting Position SWITCH successfully operates the IAM Federation SWITCHaai for the Swiss universities over ten years. The next development steps are planned and implemented with the Swiss edu-ID project, which is currently ongoing.

While SWITCHaai Identity Management (IdM) is entirely supplied at the universities, a partial centralization of IdM at the federation operator SWITCH is provided by the Swiss edu-ID. In addition to existing Access Management (AM) based on SAML / Shibboleth, new IdM tasks are moving to SWITCH.

A detailed architecture for the Swiss edu-ID has been finalized at SWITCH1. An important step for the next few months is to specify the IdM processes, evaluate IdM products and eventually make a platform choice.

2.2 Objective The objective research order was to define a long and a short list with possible solutions by the mid of July 2016. This includes an assessment of collected requirements.

The following deliverables are provided in this report:

• Catalogue of derived requirements for the new identity management solution. • Market overview of IdM systems with an assessment of the evaluated requirements. • Definition of a shortlist including alternative solutions. • Clarification of the next steps.

The following aspects were taken into account:

• The enumeration of all available products on the market, which were already known or could have been determined with an internal internet investigation.

• The including of Swiss hosted cloud solutions. • The evaluation of open source products in the same way and with the same priority as

commercial products. • A potential in-house development of an own solution as a part of the next steps recommendation.

A request for information (further referred as RFI) was sent to selected suppliers from the previously defined longlist and the result was analysed. The evaluation has taken the particular characteristics into account:

• Support level of the use cases. • Web capabilities of the solution, a 100% was defined to be achieved. • The full possibility to integrate the existing Access Management, provided by the SWITCHaai

infrastructure based on Shibboleth into the future solution. • The ability to the IdM provisioning interface to support highly distributed federated organisations

like Swiss academia, e.g. by solely relying on open standards and APIs. • Scalability to handle up to three million users. 1 All public documents of the Swiss edu-ID project: https://projects.switch.ch/eduid/documents/

Classification: Public 6/31

• The strategic focus in user-centric identity Management.

2.3 Scope and Demarcations • Cloud services operated outside Switzerland were out of scope. • Only the Identity Management part was taken into account, the existing Access Management

base on Shibboleth was not re-evaluated.

Classification: Public 7/31

3 Swiss edu-ID IdM

Swiss edu-ID Identity Management (IdM) is part of the Swiss edu-ID target architecture and intended to manage Swiss edu-ID identities stored in the Swiss edu-ID system.

3.1 Goals of Swiss edu-ID The Swiss edu-ID is a digital identity SWITCH is developing for persistent use by university members as an evolutionary extension of SWITCHaai, SWITCH's successful identity management solution. Compatibility of the Swiss edu-ID with SWITCHaai is a mayor requirement.

Swiss edu-ID concept corner stones are:

• Persistency: Swiss edu-ID is built to survive organisational affiliations. Any person who is in contact with a Swiss edu-ID participating organisation may create a Swiss edu-ID account and keep this account for all of his life.

• User-centrism: Users issue their identity in a light-weight self-registration process, users bring their pre-existing identity to the university/employer, and users decide whether to pass on data to Service Providers.

• Organisational backing: Participating organisations (e.g. universities or other institutions of higher education) add or validate attributes of identities.

• Openness: Swiss edu-ID is open to members of Swiss academia and people with relation to it. • Scalable quality: Swiss edu-ID allows for low quality as a feature. However, verification

processes to increase the assurance level of attributes are foreseen. Relying parties such as Service Providers can base decisions on the assurance level of attributes.

• Swiss edu-ID User Base: The Swiss edu-ID will predominantly be used by students (300k active users), staff & researches (~150k active users), library users, university guests, alumni (growing potential up to 2 Mio users, many of them inactive) and further education students.

Swiss edu-ID is a highly distributed federation of participating organisations, with some infrastructure services operated centrally by SWITCH. Swiss edu-ID Participants and Service Providers maintain their own IT environments. The majority of participants currently operate Shibboleth as IdP.

Swiss edu-ID central services cover both Access Management (AM) and Identity Management (IdM): • Access Management (AM) includes user authentication and all components needed for identity

propagation to Service Providers, including runtime aggregation of identity attributes and user consent dialogues. Access Management is implemented with Shibboleth.

• Swiss edu-ID Identity Management (IdM) is currently a home-grown solution and may eventually be replaced by standard software if available. This is the scope of the RFI.

For further Information on Swiss edu-ID: See [Swiss edu-ID]

Classification: Public 8/31

3.2 Target Architecture and Scope of Swiss edu-ID IdM

The figure below shows the basic components of the Swiss edu-ID target architecture:

The Swiss edu-ID Identity Management consists of the following components: • User Directory: Swiss edu-ID identity information is stored in the User Directory. This

component may be part of the IdM solution or implemented separately. • User Profile Panel: A 100% web application where users manage their Swiss edu-ID account,

their Swiss edu-ID personal attributes and links to other identities. Users may also review current organisational affiliations.

• IdM Admin Panels: A 100% web application for administrators and attribute validators. • IdM Provisioning Service: A service called by Participants to pull and push information from

and to the User Directory. • Service Provider (SP) Notification: A service that notifies Service Providers on relevant

changes in the User Directory. • Audit Log: A service that ensures accountability of all management actions.

Swiss edu-ID user attributes managed by participating organisations, so-called affiliation attributes, are collected at runtime by the access management (Shibboleth) Attribute Aggregator. They may be stored in the User Directory but are not managed by the identity management components. Swiss edu-ID user attributes are propagated to Service Providers at runtime by the (Shibboleth) Attribute Filter that is out of scope of the IdM components. Please note that the organisational IdM of a Participant may also be a Service Provider and retrieve information about Swiss edu-ID accounts through the access management channel (e.g. an institutional registration service for prospective

Identity(Management((IdM):In(Scope(of(this(Request(for(Information

Access(Management((AM):Out(of(Scope((OoS)(of(this(RFI

AM((OoS)

May(be(OoS

Classification: Public 9/31

students). Swiss edu-ID IdM may also provide a push mechanism to propagate identity information to Participants.

Classification: Public 10/31

4 Sample Use Cases

Swiss edu-ID use cases are not yet finally defined. However, the sample use cases described below may provide a good impression of required Swiss edu-ID IdM functionality and your solution’s ability to meet these requirements. It is not intended to be an exhaustive set of use cases. Many important topics (such as account blocking/unblocking or account deletion) have been intentionally omitted to reduce the effort required to respond to the RFI.

Ref. Sample Use Case on edu-ID Account Creation

1 Swiss edu-ID accounts are exclusively created by users and this cannot be delegated to any third party. However, Swiss edu-ID account creation can be embedded into a larger workflow:

1.1

Within its “register as a student” workflow, an organisation redirects the user to the Swiss edu-ID account creation user panel, passing along the set of personal attributes it requires (including the required assurance level per attribute). This information is embedded in the Swiss edu-ID account creation pages in a user-friendly way, e.g. by marking the required attributes as mandatory fields.

1.2

The user provides all required attribute values. For each mandatory attribute, available processes for attribute verification are shown to the user given the required assurance level. Out of this selection, the user then triggers an attribute verification process of his choice. Users should be able to interrupt the registration process and resume at a later time.

1.3 After successful completion of the Swiss edu-ID account creation, the user is redirected back to the original workflow of the organisation.

Classification: Public 11/31

Ref. Sample Use Case on Attribute Assurance

2 Managing attribute assurance levels of edu-ID personal attributes:

2.1

All edu-ID personal attributes are stored in the user directory along with meta-data to describe the attribute’s assurance level. The following information is stored as a minimum: • The assurance level according to eCH-0171 specification (“1” | ”2” | ”3” | ”4”); • The process that was used to verify the attribute value (“processID”); • Information specific to the process (e.g. type, serial number and expiry date of the official

document used for verification, such as a passport or driving license); • The date of last verification (“timestamp”); • The validator responsible for last verification (“edu-ID identifier”).

2.2

For every edu-ID personal attribute, periodic certification of the attribute value is enforced as a function of the assurance level. As an example, the user’s postal address attribute has to be verified at least every 12 months for assurance level “3”. Well before due time, the user is notified and invited to initiate a verification process suitable for certification. If no action is taken by the user, an escalation process is triggered. If certification is not completed in due time, the attribute’s assurance level is set to “1”.

2.3

For each attribute, the currently assigned assurance level is indicated on the User Profile Panel and on all IdM Admin Panels in a user-friendly way (e.g. using symbols, colours, or numbers). Additional meta-data (see 2.1) is shown by the User Profile Panel and all IdM Admin Panels on request.

Ref. Sample Use Case on Personal Attribute Registration and Verification

3 Providing a user name attribute with assurance level “4”:

3.1

The user provides his name in the User Profile Panel. He then selects a process out of the set of supported level 4 verification processes, e.g. “in person document verification”. The user also selects a validator authorised to verify the user name attribute for level 4 assurance. Remark: Other supported processes may be “video identification” or “online identification” according to [FINMA RS 2016/7]).

3.2

The validator checks the user’s official document (e.g. a passport or driving license) in person to confirm correctness of the user name attribute value. If confirmed, the assurance level is set to “4” either manually by the validator or automatically by the organisation calling the Swiss edu-ID IdM Provisioning Service.

3.3 If names do not match, a reconciliation process is triggered.

Classification: Public 12/31

Ref. Sample Use Case on Password Management

4 A user changes his Swiss edu-ID password:

4.1 On the User Profile Panel, the user changes his password. The new password is then stored with all (e.g. 10) different hash values supported by Swiss edu-ID.

4.2 A notification is sent to all (e.g. 20) Service Providers who have subscribed to SP notifications and where this user is registered and to all (e.g. 3) Participants where this user has at least one active affiliation.

4.3 Any of these Service Providers or Participants may then request a specified hash value of the new password by calling the Swiss edu-ID IdM Provisioning Service.

Ref. Sample Use Case on 2nd Factor Management

5 A user registers a 2nd factor to be used for NIST level 3 authentication:

5.1

On the User Profile Panel, the user selects one of the 2nd factor mechanisms supported by Swiss edu-ID, e.g. the OATH soft token mechanism implemented by Google Authenticator and Red Hat FreeOTP Authenticator apps. Remark: Other supported mechanisms may be “SMS OTP (mTAN)”, “FIDO”, “SuisseID”, or “Mobile Signature Service (Mobile-ID)”.

5.2

The user is guided by the IdM process to install a suitable OTP generating app and to register the credential. Registration includes sending an activation one-time-key to any user address of assurance level 3 or higher (this may be a postal address, a phone number, or an E-Mail address).

5.3

The registration process also includes generation of suitable information to be used in a self-service recovery process in case the 2nd factor is lost by the user. Remark: Such a self-service recovery process may e.g. be based on a strike-list (or PUK), a linked identity, biometrical information or other mechanisms. However, magic questions are not considered to be adequate.

Ref. Sample Use Case on Linked Identities

6 A user links a 3rd party identity to his Swiss edu-ID account:

6.1

On the User Profile Panel, the user selects a 3rd party identity provider supported by Swiss edu-ID, e.g. ORCID. Remark: Other supported 3rd party identity providers may be social identity providers such as Google, LinkedIn or Facebook.

6.2 The user is guided by the IdM process to link his ORCID ID to his Swiss edu-ID account according to ORCID requirements (this will include authentication vis-a-vis ORCID).

6.3 A user with a linked ORCID identity has forgotten his password and uses ORCID authentication for password recovery.

Classification: Public 13/31

Ref. Sample Use Case on Duplicate Account Resolution

7 A user resolves duplicate accounts:

7.1

Swiss edu-ID IdM continuously monitors the user directory to detect duplicate accounts: • If duplicates are identified based on Swiss edu-ID personal attributes that contain unique

identifiers (e.g. linked identities such as ORCID ID, passport number, or a public key of a 2nd factor device) or addresses (e.g. E-Mail address, mobile phone number), the user of the duplicate accounts is notified and forced to merge duplicates within a defined period of time.

• If duplicates are presumed based on other Swiss edu-ID personal attributes (e.g. matching names and dates of birth, matching home addresses, matching landline phone numbers), the users of the duplicate accounts are notified and requested to either approve or merge the respective accounts.

7.2

The user responsible for the duplicate accounts merges the duplicates into one account. For this, he has to authenticate for both accounts. The deduplication process supports the user by providing suggestions how to merge best and in a way that attributes with already higher assurance level or the profile already used are preferably kept.

7.3 After completion of the duplicate account resolution, a notification is sent to all (e.g. 20) Service Providers where at least one of the duplicate accounts was registered and to all (e.g. 3) Participants where at least one of the duplicate accounts had an active affiliation.

Ref. Sample Use Case on Attribute Query

8 Swiss edu-ID IdM provides identity information to various stakeholders:

8.1

Using the User Profile Panel, a user may request to see all his Swiss edu-ID attributes. At least the following attributes will be shown in a user friendly way: • Swiss edu-ID personal attributes with current assurance level and meta-data; • Swiss edu-ID account information such as account status or last date of modification; • Swiss edu-ID credential information such as a token serial number or a public key (secret

credentials such as symmetric keys or password hashes are not shown); • All current and former affiliations and all service providers where the user is registered; • All current affiliation attributes and all former affiliation attributes.

8.2

By using an IdM Admin Panel or by calling the IdM Provisioning Service, a Participant may request to see all Swiss edu-ID personal attributes, current affiliation attributes, and former affiliation attributes of all accounts that have a current affiliation with the organisation. The requested information is provided in a suitable electronic format (e.g. an XML file).

Classification: Public 14/31

Ref. Sample Use Case on Managing Attribute Validators

9 Swiss edu-ID Attribute validators responsible for attribute verification are managed by the operator (i.e. SWITCH):

9.1

For attribute assurance levels “3” and “4”, attribute verification processes may require approval of a trusted validator. Validators are authorised along the following dimensions: • Authorisation to verify personal attributes of a user based on his affiliation(s) with an

organisation (this authorisation may be given to a university’s matriculation desk); • Authorisation to verify a specific attribute up to a specific assurance level for all users

(this authorisation may be given to a group of persons that are specifically trained to verify official documents in person or to use online-identification tools such as WebID).

9.2 On the User Profile Panel, all validators authorised to verify an attribute up to the requested assurance level are shown to the user. Out of this group, the user may select the validator of his choice without further restriction.

9.3 If the attribute assurance level is confirmed by the validator manually on an IdM Admin Panel, the validator’s authentication level must at least match the assurance level of the attribute he confirms.

Ref. Sample Use Case on Organisational Attribute Change

10 A user changes his last name (e.g. because of a marriage).

10.1

If the user is affiliated with an organisation: The user is affiliated with an organisation and initiates the name change within Swiss edu-ID user profile panel. The new name is set on a status (on hold, to be verified). The organisation is informed of the change and can then initiate an individual verification process and afterwards set the attribute value and assurance level. All other participants with active affiliations are informed with a push notification immediately.

10.2 If the user has no active affiliation: The name change decreases the assurance level. The user is guided through the process to verify the new name and increase the assurance level.

10.3 All participants and Service Providers that were used by the user are informed with a push notification of the attribute change.

Classification: Public 15/31

5 Market Analysis (Long List)

The following manufacturers, consultants and integrators in the field of identity management were identified and collected in a long list:

Classification: Public 16/31

Product

Com

mer

cial

SW

O

pen

Sou

rce

Ser

vice

(Saa

S)

Sub

sidi

ary

in C

H

Res

pond

to In

vita

tion

RFI

Req

uest

ed

RFI

ans

wer

ed

AdNovum NEVIS Product Suite

http://www.adnovum.ch/angebot/produkte/nevis.html

AdNovum Informatik AG Phone: +41 44 272 61 11

Integration Partner

Directly supported by AdNovum

X X X X X

Atos DirX Directory and DirX Identity

http://atos.net/en-us/home/we-do/cyber-security/identity-and-access-management-with-dirx/dirx-identity.html

Atos Schweiz Phone: +41 58 702 11 11 [email protected]

Integration Partner

For Swiss edu-ID: Directly supported by Atos

X X X X X

Apache Syncope

https://syncope.apache.org/

Integration Partner

Tirasa S.r.l. Phone: +39 0859116307 [email protected]

http://www.tirasa.net/

X X X X

Avatier Identity Enforcer

http://www.avatier.com/products/identity-management/it-service-catalog-user-provisioning/identity-enforcer/

Avatier Corporation Phone: +44 207 877 18 07 [email protected]

X X X

CA CA Identity Suite / CA Identity Manager X X X X

Classification: Public 17/31

Product

Com

mer

cial

SW

O

pen

Sou

rce

Ser

vice

(Saa

S)

Sub

sidi

ary

in C

H

Res

pond

to In

vita

tion

RFI

Req

uest

ed

RFI

ans

wer

ed

Technologies http://www.ca.com/us/products/ca-identity-suite.html

CA (Schweiz) Phone: +41 44 804 78 78 [email protected]

Integration Partner

Vero Certus GmbH http://www.vero-certus.com

Courion Account Courier

http://www.courion.com/account-courier/

Courion UK Corporation Ltd Phone: +44 800 048 8651 http://www.courion.com/contact-us/

X

Covisint Enterprise-grade Identity Management

http://www.covisint.com/solutions/identity-and-access-management/

Covisint GmbH Phone: +49 6102 5 79 70 17 [email protected]

X X X

BCV solutions

CzechIDM

http://www.czechidm.com/

BCV solutions s.r.o. Phone: +420 724 111 809 [email protected] http://www.bcvsolutions.eu/en

X

DAASI international

Identity Management

https://daasi.de/

DAASI International GmbH Europaplatz 3 D-72072 Tübingen

Phone: +49 7071 407109 0

X X X

Classification: Public 18/31

Product

Com

mer

cial

SW

O

pen

Sou

rce

Ser

vice

(Saa

S)

Sub

sidi

ary

in C

H

Res

pond

to In

vita

tion

RFI

Req

uest

ed

RFI

ans

wer

ed

[email protected]

Dell Identity Manager

http://software.dell.com/products/identity-manager/

Dell Security Phone: +41 844 822 844

X X X X

EMC RSA Via Lifecycle and Governance

http://switzerland.emc.com/security/rsa-via-lifecycle-governance/rsa-via-lifecycle.htm

EMC Computer Systems AG Phone: +41 43 444 66 66

Integration Partner

Axalon GmbH http://www.axalon.ch

X X X X X

EmpowerID Identity Management & Cloud Security

https://www.empowerid.com/

The Dot Net Factory, LLC Phone: +1 877 996-4276 [email protected]

X X X

Ergon AirLock IAM

https://www.airlock.com/de/produkte/airlock-iam/

Ergon Informatik AG Phone: +41 44 268 89 00 [email protected]

X X X X

Evidian Identity and Access Manager

http://www.evidian.com/products/identity-and-access-manager-for-

identity-and-access-governance

Evidian GmbH Phone: +49 211-399-38487 http://www.evidian.com/company/contact-us/

X X

Classification: Public 19/31

Product

Com

mer

cial

SW

O

pen

Sou

rce

Ser

vice

(Saa

S)

Sub

sidi

ary

in C

H

Res

pond

to In

vita

tion

RFI

Req

uest

ed

RFI

ans

wer

ed

Evolveum MidPoint

https://evolveum.com/midpoint/

Evolveum s.r.o. Phone: +421 2 3211 7191 [email protected]

X

ForgeRock OpenIDM

https://www.forgerock.com/platform/identity-management/

ForgeRock Germany Phone: +49 211 88 23 15 78

Integration Partner

iC Consult GmbH http://www.ic-consult.com/de-CH/home-ch.html

X X X X X

Gemalto Identity & Access Management Solutions

http://www.gemalto.com/enterprise-security/identity-access-management

Gemalto Phone: +41 22 747 78 26 http://www.gemalto.com/companyinfo/contact-us

X

IBM IBM Security Identity Governance and Administration

http://www-03.ibm.com/software/products/de/category/identity-access-management

IBM Schweiz Phone: +41 58 333 44 55

X X X X

Microsoft Forefront Identity Manager 2010 R2

https://www.microsoft.com/de-ch/server-cloud/products/forefront-identity-manager/

Microsoft Schweiz GmbH Phone: +41 848 22 44 88

X X X

Classification: Public 20/31

Product

Com

mer

cial

SW

O

pen

Sou

rce

Ser

vice

(Saa

S)

Sub

sidi

ary

in C

H

Res

pond

to In

vita

tion

RFI

Req

uest

ed

RFI

ans

wer

ed

Micro Focus Identity Manager

https://www.netiq.com/products/identity-manager/advanced/

Flughafenstrasse 90 Phone +41 43 45 62 30 [email protected]

Integration Partner

SkyPRO AG Phone: +41 41 741 47 70 http://www.skypro.ch/de

X X X X X

Okta Provisioning

https://www.okta.com/products/provisioning/

Okta EMEA Benelux [email protected]

X

Omada Omada Identity Suite

http://www.omada.net/omada-identity-suite-417.aspx

Omada GmbH Phone: +49 6151 971975 8 [email protected]

X

OneLogin OneLogin WAM (Web Access Management)

https://www.onelogin.com/product/user-provisioning

OneLogin Ltd Phone: +44 808 109-3898 [email protected]

X X X X

OpenIAM OpenIAM Identity Manager

http://www.openiam.com/

OpenIAM [email protected]

X

Oracle Oracle Identity Management X X X X

Classification: Public 21/31

Product

Com

mer

cial

SW

O

pen

Sou

rce

Ser

vice

(Saa

S)

Sub

sidi

ary

in C

H

Res

pond

to In

vita

tion

RFI

Req

uest

ed

RFI

ans

wer

ed

https://www.oracle.com/middleware/identity-management/index.html

Oracle Software (Schweiz) GmbH Phone: +41 56 483 31 11 [email protected]

OSIAM Open Source Identity and Access Management

http://osiam.github.io/

tarent solutions GmbH Phone +49 228 548 81 0 [email protected]

X

SailPoint IdentityIQ

https://www.sailpoint.com/products/identityiq

SailPoint Technologies, Inc. Phone: +33 6 89 28 64 38 [email protected]

X X X X

SAP SAP Identity Management

http://help.sap.com/nwidm80

SAP (Schweiz) AG Phone: +41 58 871 61 11 https://go.sap.com/swiss/registration/contact.html

X X

Soffid IAM

http://soffid.com/features/identity-management/

Soffid X X X

WSO2 WSO2 Security Platform

http://wso2.com/products/identity-server/

WSO2 Inc. Phone: +44 203 318 6025 http://wso2.com/contact/

X X X X

Classification: Public 22/31

6 RFI Overview

6.1 RFI Timeline Date Deliverable

2016-04-27 Vendors are informed about the RFI and invited to participate

2016-05-04 RFI is sent to vendors

2016-05-22 Latest date for vendor answers to the RFI

2016-06-01 Vendors are informed about RFI evaluation and selected vendors are invited to a presentation workshop

2016-06-06 to 2016-06-10 Presentation workshops

2016-07-15 Vendors that participated in a presentation workshop are informed about further proceedings in the project

6.2 Collected Information In order to be able to complete the picture of all the participating solutions, the following topics were asked as a part of the RFI:

• Company and support • References • Environmental fit • Product architectural fit • Operation • Licensing / cost • Sample use cases

It is important that the Swiss edu-ID Identity Management components fits the highly distributed federated environment of Swiss edu-ID as well as possible. In order to guarantee this requirements, the following questions were asked as a part of the RFI:

Classification: Public 23/31

Topic Question

100% web based Is the IdM user interface both for end users and administrators 100% web based?

Shibboleth integration

Can the logon to Swiss edu-ID IdM Admin Panels and User Profile Panel be based on Shibboleth (see http://shibboleth.net/)?

Federated provisioning

Do the IdM Provisioning interfaces to participating organisations support the highly distributed federated nature of Swiss academia, e.g. by solely relying on open standards and APIs?

Scales up to 3 Mio. users Do the Swiss edu-ID IdM components scale up to 3 million users?

User-centric identity mgmt.

Does your solution fully support the user-centric identity management paradigm of Swiss edu-ID where the identity is owned and managed by the user, verified and enriched by organisations?

These questions have significantly reduced the number of returned RFI answer sheets. Especially the large enterprise companies have mostly products with an internal enterprise IAM focus. This means they are specialised either on entitlements and role management or on identity and access governance. Many of those participants decided not to answer the RFI.

In order the estimate a business case, a price indication is important to know from the beginning. SWITCH as a foundation has the obligation to the members to implement high efficient solution on an acceptable cost level. Therefore, the following additional questions were asked as a part of the RFI:

Topic Question

Licensing Cost

Please explain your licensing model. Please answer the following additional questions based on your answer in chapter 4.5 “Operation” in the RFI for 20k, 300k and 3M identities: • What is the licence cost for the minimal version? • What is the licence cost for the best practise version?

Integration Cost

Please estimate the effort to integrate your product in the switch environment, including support of all sample use cases (both monetary and person days).

For more details about the question in the RFI, please refer to the public Swiss edu-ID documents2, section RFI IdM 2016.

2 https://projects.switch.ch/eduid/documents/

Classification: Public 24/31

6.3 Evaluation Procedure Based on the information collected, the project team evaluated the shortlist members by executing the following the processes steps:

• Centrally storing of all the RFI answer sheet, attachments and the whole email communication on the project storage as a clear base of information for all experts.

• Creating a forced ranking from five to one, as well as a defining the strength and weaknesses for all eight answered RFIs. In order to increase the quality, five independent experts, analysed the products individually and documented the results in a pre-defined template (3x SWITCH and 2x Temet experts).

• A consolidating workshop has been held for defining the final version of the shortlist. Four recipients were chosen as a result of the discussion.

• All participants have been informed about the result. The members of the shortlist were invited to were invited to the presentation workshop, the others were adopted the a thanks for their participation.

• Presentation workshops have been processed following a pre-defined agenda • Impressions about the presented workshops were discussed in the team as a part of the de-

briefing.

6.4 Evaluation Results The following chapter is structured in:

Overview: The overview contains a benefit analysis with a ranking from 1 to 5 symbolized with smileys. All products have been classified, as far as the quality of the answers was high enough in order to do the ranking.

Summary of Forced Ranking: This chapter contains the summarized scores of the individual expert analysis for each product.

Overall assessment of the shortlist members: This contains all recognitions as well as the pro and cons in a summarized version for the individual products on the shortlist.

Classification: Public 25/31

6.4.1 Overview

Legend General Questions Sample Use Cases !! Very strong point

Com

pany

and

Sup

port

Ref

eren

ces

Env

ironm

enta

l Fit

Pro

duct

Arc

hite

ctur

al F

it

Ope

ratio

n

Lic

ensi

ng /

Cos

t

Acc

ount

Cre

atio

n

Attr

ibut

e A

ssur

ance

Attr

ibut

e V

alid

atio

n

Pas

swor

d M

anag

emen

t

2nd

Fac

tor M

anag

emen

t

Lin

ked

Iden

titie

s

Acc

ount

De-

dupl

icat

ion

Attr

ibut

e Q

uery

Man

agin

g V

alid

ator

s

Cha

nge

shar

ed A

ttrib

ute

! Fulfilled R

emar

ks /

Invi

ted

to W

S

" Partially fulfilled / neutral

# Not fulfilled / not available

!!

## Very weak point (i.e. a “killer”)

!!

Vendor / Integrator !!

(randomized, anonymized) !!

A " " " 2) " ! " " # 8) " 9) ! 11) # 13) " 14) " 17) ! # 8) " 9)

B ! ! " 2) ! ! ! " # 8) " 9) ! 10) " 9) # 15) " 17) ! # 8) " 9)

C " N/A # # N/A Not

RFI response did not address any Swiss edu-ID use case Focused on Enterprises provided

D " ! 1) !! !! 3)

!! 4)

!! 5) # 6) # 8) # 18) ! 10) " 9) " 14) # 18) " 19) # 21) " 9)

Cheap Costs / Higher dev.

effort

E ! ! " 2) " ! # ! 7) " 8) " 9) ! 10) # 13) ! 16) " 17) ! # 8) " 9)

F ! ! ! ! ! " " " 8) " 9) ! 10) !! 12) " 14) " 17) ! " 20) " 9)

G # " ! ! " ! 5) " # # # # # # ! # # Is focused on AM

H " ! ! # ! Not

RFI response did not address any Swiss edu-ID use case Is focused on AM provided

1) References in universities

2) Shibboleth logon experience

3) IDM only

4) Fully F/OSS

5) No subscription

6) Only few workflows

7) REST IF defined

8) Schema extension

9) Workflow configuration

10) Single hash

11) Single cipher

12) Various tokens

13) Managed separately

14) IdP configuration

15) New feature

16) “Social Access”

17) Configure task

18) Develop task

19) GUI configuration

20) On roadmap

21) Authz core

6.4.2 Summary of Forced Ranking

The consolidation of the expert based force ranking from the RFI results at May 25th 2016 has given the following results:

Product3 Score

D 20

F 17

B 10

E 10

G 8

A 5

C 0

H 0

Total 70

As a part of the consolidation workshop, the decision for inviting the first four participants was made. Two products with zero points were not discussed anymore, since all experts came to the conclusion that these products do not fit the requirements.

6.4.3 Overall Assessment of the Shortlist Members

The first four participants of the short list have been invited to present their product, solutions for some of the described use cases and to answer specific questions concerning their product(s) and 3 Product and vendor information is anonymized in the public version of this report.

Classification: Public 27/31

company. All four companies followed the invitation and gave a 3 hour presentation with discussion in May 2016. The overall impression and points of special interests were discussed afterwards within the experts group. Positive and negative aspects of the product(s), company, development effort, interfaces etc. have been collected. This part showing the consolidated results in detail is only available in the community confidential version of the report.

Classification: Public 28/31

7 Conclusion

7.1 General conclusion The market analysis has shown that a variety of products are available. Many products are designed for the classic areas of enterprise IAM. The focus on business to customer in a federated environment is in many products either not available or just a functional extensions to the enterprise core. None of the analysed products is able to fulfil all requirements by using built in features. A higher amount of customizing or even development is expected at all of the analysed solutions. The provided license models are as per user in all products. In certain cases, there is a differentiation between active and inactive users. The focus on a per user base shows, that the most products have a focus on enterprise IAM.

By means of the analysis we have found different open source products on the market. It turned out, that most of the open source products have issues in their sales management processes. Many communities did not react on the RFI from our side. At the end we just had Apache Syncope and product A4 on the shortlist. Regarding product A, it turned out that the open source version has no commercial support at all. The community version must be individually backported by the customer based on nightly builds. There are no typical open source project structures available with product A and no democratic election processes implemented, for example to define the roadmap. Apache Syncope is the only product with a traditional open source setup that has answered. The RFI has been answered by Tirasa as one of the main committers in the project.

The situation regarding development possibilities is different between the individual products. In general open source solutions support most of the common development environments. Since the code base is open, there are hardly any limitations at all. In case of Apache – Syncope, the accuracy and completeness of the documentation is not guaranteed. All commercial products have development interfaces covering more or less the main functionally of the application. Furthermore, all analysed commercial products are based on proprietary components, which cannot be programmed individually. Since all analysed products do not cover the requirements out of the box, a high effort of development is expect and therefore API coverage is an important point.

The following chapters describe the conclusions in a categorized and more detailed way:

4 Product and vendor information is anonymized in the public version of this report.

Classification: Public 29/31

7.2 Pricing Regarding the price situation, the following conclusions can be mentioned:

All commercial players have a lot of space regarding price negotiations. Product E had initially a very high licensing price indication in the RFI. This price became reduced by 80% in the evaluation time with no special negotiation.

We expect license costs around 500 k CHF plus 20% to 25% for yearly maintenance for all three commercial products.

Open source is free of licence costs. Maintenance and support can be agreed separately as an option.

7.3 Development None of the participating products cover all requirements out-of-the box. Especially the attribute assurance and the de-duplication processes are not built-in features of any solution.

Custom solutions, including add-ons, special developments or customizing is required in any case.

We expect development efforts (excluding specification, integration and testing at SWITCH) of around 300 to 400 person days for all solutions.

The main emphasis on the four candidates is expected like the following:

Customizing Development

E B, D, F

7.4 Collaboration The collaboration models are different between the analysed products. We expect that in all cases there will be need for support by an integrator. Some products are designed to have higher customer autonomy in making individual developments. Others are mainly focused on contractual development by the software publisher with a marginal customer involvement.

We classified the analysed products in to the following categories:

Own Customer Development possible Software Publisher Development required

D, E B, F

Classification: Public 30/31

7.5 Roadmap Influence The influence on the product roadmap depends on the size of the company and its customer base. The bigger a company, the less influence on the roadmap. Open source is a special case. There are typically democratic structures in the communities deciding about the roadmaps. This makes the process of decision less predictable and there is a potential risk that important changes are denied by the community.

We rated the products in the following three categories:

Hardly any Influence Partial Influence Substantial Influence

B, E F D

7.6 Roadmap Fit The currently published roadmaps of the analysed products fit either in the category Enterprise IAM or Business to Customer (B2C) IAM. We expect a roadmap focussed on B2C IAM as more accurate as better fitting the Swiss edu-ID.

The following product classification is the conclusion of the analysis:

Business to Customer IAM Enterprise IAM

F B, D, E

7.7 Product Stability and Strategic Relevance The analysis of the product presentations showed a difference in the stability expectations and strategic relevance of the products. We classified the solutions into the following three categories:

Core Business and Strategic Orientation

Really Small Company, but Strategic Focus

Different Products in-House, Unclear Consolidation Strategy

E, F D B

Company B has multiple products in-house and with the acquisition of another company they provide integration of other third party products as well as selling their own products. Furthermore, a part of their products need a technical redesign in certain areas. Therefore we expect a lot of consolidation work at company B regarding the products and strategy in the near future.

7.8 Capital Expenditure and Scalability In case of the product D, it is possible to “start small” and develop the solution to a bigger platform over time. In case of products B, E and F we consider this as unrealistic due to infrastructure requirements and licensing model.

Classification: Public 31/31

8 Next Steps

As a part of this recommendation, we suggest to focus on Apache – Syncope with Tirasa (product D). This product fits the already existing environment of SWITCH and has convinced in the RFI process.

As the procedure model we recommend building the new solution in parallel to the existing infrastructure using a prototyping approach. Therefore we suggest the definition of iterative and incremental procedures with clear break points defined.

If it turns out that product capabilities are insufficient, other options must be checked immediately. In such a case we recommend to clarify further open source alternatives. Another fall back option would be to return to the decision regarding product F or other commercial players on the RFI Shortlist.

We recommend the following next steps:

Nr. Task Description Date Reference

1 Clarification if an individual development is realistic. Therefore an estimation of the effort and a risk assessment must be done. If this is really an option to go, return to the decision by the management.

Q3 2016

2 Definition of Swiss edu-ID IdM roadmap as a part of the overall roadmap. The reference dates following below are depending on the roadmap definition and internal priorities.

Q3 2016

3 Rebuild the Swiss edu-ID Version 1 infrastructure in the prototyping environment. Use the new system as a non-productive test system to collect experience and to get a feeling about Apache Syncope solution.

Q4 2016

4 Build two to five future use case scenarios as a proof of concept based on the prototyping infrastructure in order to confirm the capabilities of the Syncope regarding future development.

Q4 2016

5 Rebuild the Swiss edu-ID Version 2 on the prototype, still as non-productive.

Q1 2017

6 Migrate the data from the productive environment to the new prototype based infrastructure.

Q2 2017

7 Run intensive tests like integration, usability, availability und regression tests.

Q2 2017

8 Switch existing productive environment to the new prototype. Q2 2017

9 Implement further use cases as a part of the regular release management.

Q2 2017