Sep 05

© 2016 SecurIT

Challenges in Authentication-

and Identity Management

“CAMINANTE NO HAY CAMINO,

SE HACE CAMINO AL ANDAR”

ISEC INFOSECURITY TOUR 2017

05.09.2017, Buenos Aires, Argentina

2© 2

016 S

ecurI

T

Who is MerStar?

• Founded 2013 in Switzerland

• IT Security Projects for banks, insurance companies, governments

• Architecture-driven approach from requirements phase to actual

production launch

• SecurIT Business Partner

3© 2

016 S

ecurI

T

Who is SecurIT?

• Founded in 1999 in Belgium

• Offices in BE, NL and USA

• Security vendor

• Focus in Identity and Access Management

• Various IDM products

• Technology Partners• Vasco, PhoneFactor, Gemalto, RSA SecurID, Kobil

• Id-me, SentryCom

• IBM, CyberArk

• Customer references

4© 2

016 S

ecurI

T

Authentication: Traditional Deployment Scenario

BrowserApplication

Server

LDAPServer

Proxy

Authentication

Server

One-Time-Password

Smartcard(e.g. eID)

Username/Password

AD

Internet DMZ Intranet

Browser

5© 2

016 S

ecurI

T

Cloud Computing, Desktop SSO, Social media

Identities (IdP) are no longer strictly local

Applications (SP) are no longer strictly local

Private IdP

Private SPCisco WebEx

6© 2

016 S

ecurI

T

Cloud services: Traditional Authentication requires integration with Federation

Application

Server

LDAP

Server

Proxy

Authentication

Server

One-Time-Password

Smartcard

(e.g. eID)

Username/

Password

AD

Internet of SPs and IDPs DMZ Intranet

Cisco WebEx

Browser

Browser

7© 2

016 S

ecurI

T

Integration challenges

• How do I become a SP?

• Which protocol ?

• SAML2, WS-Federation, Oauth2, OpenID Connect, XAML

• How do I manage the technology?

• How do I manage my identities?

• Provisioning and life cycle?

• Legal on-boarding?

8© 2

016 S

ecurI

T

Recommendation (1) – Think Authentication Broker !

Extend the protocol stack but keep traditional functions…

9© 2

016 S

ecurI

T

Recommendation (2) – Authentication Broker becomes Federation Broker

• Architecture Principle

• Brokers the relationship between SP(s) IDP(s)

• Issues Federation Token

• Support features such as IDP discovery, Single Logout

and Provisioning protocols

10© 2

016 S

ecurI

T

Avoid multiple access points such as

https://idpforsp1.mycompany. com

https://idpforsp2.mycompany. com

https://idpforsp3.mycompany. com

Prefer Single access point such as

https://idp.mycompany.com

Recommendation (2) – Authentication Broker becomes Federation Broker

11© 2

016 S

ecurI

T

Recommendation (3) – Protect the application

• 90% of the IT investments are in applications

• Logon to the application using a token which

• is standardized (format and content) – i.e. SAML2

• Have an in-house “Token Specification”

• Standardize Identity Token (same for all apps)

• Define a “shopping list” for access control attributes

Federation Token

• Have a common “Identity Framework”

• Transform token to API

• Single API for user-id and security context

i.e. Java / .NET based

• Propagate Token through all layers

• End-to-end security, propagate issuing token

through all layers up to enterprise tier

12© 2

016 S

ecurI

T

SecurIT

info@securit.biz

www.securit.biz / www.trustbuilder.eu

http://bit.ly/1R3DkZM

Marc Vanmaele

marc.vanmaele@securit.biz

mvanmaele

New YorkGent Amsterdam

Visit us in the Exhibition Area

Stand 12

Karsten Oliver Starr

karsten-oliver.starr@merstar.ch

Muchas gracias…

13© 2

016 S

ecurI

T

Identity Federation? Quick refresh...

Identity

Provider (IDP)

Requestor

Service

Provider

(SP)

14© 2

016 S

ecurI

T

Backup Slides - Other Recommendations

• Have an End-to-end architecture

• Buy, don’t build

• Protect the „legacy* systems (i.e. authorization systems)

• Do NOT throw well-established systems away because they are old, protect the wel-established resources

such as workflows and business processes

• Rather „renovate“ existing systems wherever possible and keep them

• Have a good product set for Reverse Proxy and Authentication Server

• But protect well-established systems and renovate wherever possible

• Design the application with security in mind (OWASP Top 10)

• Security in design process at all stages

15© 2

016 S

ecurI

T

Cloud Computing and Social media challenges

Identities (IdP) are no longer strictly local

Applications (SP) are no longer strictly local

Private IdP

Private SPCisco WebEx

16© 2

016 S

ecurI

T

Backup Slides - Business Requirements

• Regulatory- and law enforcements

• Banking laws

• IT Diversity

• Legacy

• Mergers and Acquisitions

• Emerging standards

• Time to market

• Keep IT costs low

17© 2

016 S

ecurI

T

Backup Slides - Authentication Service requirements

• Support Multiple Authentication mechanisms

• PKI, OTP, uid/pw, OAUTH, SAML, WS-Federation, Transaction sgining

• For multiple client devices

• Mobile, Browser

• Across Multiple SSO protocols

• SAML2P, WS-Federation, OAUTH2

• Across multiple transports

• HTTP, HTTP-REST, RPC

• Supporting multiple identities

• Google, Facebook, Swift,

• Supporting Business Security requirements

• Cross border policies, Authentication- and data rules

• Non-repudiation Step-up, Step-down

• Inactivity- Max security timeouts

• Replay detection

• ...

18© 2

016 S

ecurI

T

Backup Slides - Identity Hub: The Implementation

• Where Are You From

• Not a standard

• Various proprietary implementations

• Often limited to SP cookie

• Supported by TrustBuilder

• Common Domain Cookie

• Profiles for SAML 2.0 specification

• Not very practical

• Scalability and security issues

• Supported by TrustBuilder

• IdP Discovery Service

• OASIS IdP Discovery Service specification

• OpenID Connect Discovery

• SP needs to be IDS enabled

• Supported by TrustBuilder

• TrustBuilder IdP Selection Service

• TrustBuilder acts as a proxy

• TrustBuilder terminates the Authentication Request

• TrustBuilder executes IdP selection policy

• TrustBuilder can leverage TrustFactor IdP Discovery & Attribute Provider

• TrustBuilder initiates new Authentication Request

19© 2

016 S

ecurI

T

Backup Slides - Identity Hub: High-Level TrustBuilder Architecture

IdP

(eID)

IdP

(Social Media)

IdP

(SaaS)

SP

TrustBuilder

Server

SP SP

IdP IdP IdP

Cloud ApplicationsApplications Using

ADFS

PoC (WAM, VPN,

eSSO)

User

SP

(OAuth)

SP

(WS-Federation)

SP

(SAML 2.0)

Identity Providers

TrustBuilder IDHub

Virtual SP Layer

Orchestration Layer

Virtual IdP Layer

TrustBuilder

Repository

TrustBuilder

Gateway

20© 2

016 S

ecurI

T

Backup Slides - Identity Hub: High-Level TrustBuilder Architecture

SP

TrustBuilder

Server

SP SP

User

Identity Providers

Service Providers

TrustBuilder IDHub

Virtual SP Layer

Orchestration Layer

Virtual IdP Layer

TrustBuilder

Repository

TrustBuilder

Gateway

Application Server

Off-the-Shelf

Local

Common

Applications

IdP

Application Server

Adobe EM

Local Federated

Applications

IdP

Local AuthenticationUsername/Password

One-Time-Password

Certificates

Out-of-band

IdP

SalesForce

ServiceNow

Office 365

WorkDay

Cloud

Applications

3rd Party AuthenticationVasco DigiPass

Gemalto

Safenet

Cloud

AuthenticationeID Fedict

Google+

Facebook

LinkedIN

21© 2

016 S

ecurI

T

Complete Picture

22© 2

016 S

ecurI

T

TrustBuilder

Server

External

User

TrustBuilder

Repositories

TrustBuilder

Gateway

LB/WAF

Protected

Application

TrustBuilder

GUI Server

DMZ IntranetInternet

Protected

Application

TrustBuilder

Gateway

LB/WAFInternal

User

TrustBuilder

Server

TrustBuilder

Gateway

TrustBuilder

Gateway

TrustBuilder

Repositories

Secure Intranet

TrustBuilder

GUI Server

Restricted Intranet

Connection Setup

Connection SetupLog Archive

Server

Admin.

User

Backup Slides - TrustBuilder IDHub Redundancy

23© 2

016 S

ecurI

T

External

UserLB/WAF

Protected

Application

TrustBuilder

GUI Server

DMZ IntranetInternet

Protected

Application

ISAM

WebSEAL

Secure Intranet

Restricted Intranet

Log Archive

Server

Admin.

User

Authn

Repository

TrustBuilder

Repository

Authn

Repository

TrustBuilder

Repository

TrustBuilder

GUI Server

Identity Hub

(TrustBuilder Server)

Identity Provider

(TrustBuilder Server)

Identity Provider

(TrustBuilder Server)

Identity Hub

(TrustBuilder Server)

ISAM

WebSEAL

24© 2

016 S

ecurI

T

TrustBuilder Identity Hub

Web Access Management Proxy

Federation

Provider

LDAP

RADIUS

User

Portal

TrustBuilder IDHub

Admin

Portal

Authn Service

Directory Service

Federation

Consumer

TrustBuilder Identity Hub Architecture

The User Portal exposes self-service functions like

account management, authentication enrolment, IdP

preference, device enrolment

The Admin Portal provides administrative

functions like user, group and role management,

IdP and SP onboarding and authentication

mechanism activation

Note that a TrustBuilder Identity Hub instance is

dedicated to a single organisation. Hence there is no

need for embedded multi-tenancy.

This end-point allows applications that

use RADIUS as an authentication

protocol (e.g. VPN) to leverage the

services of the Hub.

The LDAP end-point provides a virtual directory

interface that can be used by applications to

authenticate users or to retrieve attributes from the

Hub’s LDAP or from Federated repositories

(Database, LDAP, AD)

The Federation Provider end-point allows the

Hub to be used as a virtual IdP supporting

protocols like SAML, OAuth, OpenID Connect

and WS-Federation. It comes pre-configured for

a range of well-known SPs like Salesforce, and

Google Apps. Other SPs can be added using

the Admin Portal.

The Hub has an embedded Web Access Management

Proxy. The proxy is used by the Hub to proxy

federation requests between SPs and IdPs. Optionally

however the proxy can also be used to protect and

provide SSO to web applications that are not federation

enabled.

The Federation Consumer interface allows the Hub to relay requests it

can’t handle locally to external IdPs. The Hub comes out-of-the-box with a

range or pre-configured IdP (e.g. Google, Facebook, Twitter, Clef, eID).

Other IdPs can be added through the Admin Portal. The choice of IdP is

controlled by an orchestration workflow that can also be managed using

the Admin Portal.

The Hub has an embedded and replicated Directory

Service on board. This service is used to store and

manage the bridging of identities. Optionally, it can

also be used for authenticating the user using any of

the embedded authentication mechanisms. It is also

possible to leverage an existing LDAP, AD or

database server. The service supports SCIM.

The Hub also has an embedded Authentication

Service that provides several ready-to-use

authentication mechanisms. Among these

mechanisms are Username/Password, OATH-based

OTP over SMS and on mobile devices, out-of-band

and PKI (e.g. eID and other smartcards). In the context

of PKI it also provides CA fail-over and caching.