1 Managing Portal Access - Hitachi ID...

1 Managing Portal Access

Managing the User LifecycleAcross On-Premises andCloud-Hosted Applications

Onboarding, supporting and deactivating users in an Extranet B2B portal

2 Hitachi ID

© 2018 Hitachi ID Systems, Inc. All rights reserved. 1

http://Hitachi.com/

Slide Presentation

2.1 Hitachi ID corporate overview

Hitachi ID delivers access governanceand identity administration solutionsto organizations globally.Hitachi ID IAM solutions are used by Fortune500companies to secure access to systemsin the enterprise and in the cloud.

• Founded as M-Tech in 1992.• A division of Hitachi, Ltd. since 2008.• Over 1200 customers.• More than 14M+ licensed users.• Offices in North America, Europe and

APAC.• Global partner network.

2.2 Representative customers


Slide Presentation

2.3 Hitachi ID Suite

3 The challenge


Slide Presentation

3.1 B2B Portal Relationships

Hosting Organization

Partner Organization

Partner Organization

Internal User

Partner User

Internal User

Internal User

Partner User

Partner Admin

Partner User

Partner User

Partner Admin

3.2 Cost and security

Business enablement Support cost Security

• Need to onboard,manage very largenumbers of users.

• Affiliated with hundredsof organizations.

• Must have unique,memorable IDs.

• No single system ofrecord.

• Limited insight into whento create/delete IDs.

• Users who sign ininfrequently often forgettheir credentials.

• Many users but a verysmall support budget.

• Partners rarely notifyabout departed users –orphan accounts.

• Unused accounts anattractive target forpassword guessing.

• Internet-facing portal canbe attacked by anyone(no perimeter defense).

4 Solution


Slide Presentation

4.1 Unique identifiers

Requirement Implication

• User IDs must be globally unique, acrosspartner organizations.

• Otherwise, user would have to specifycustomer ID at login time – leakscustomer data to the Internet.

• Cannot use employee number,partner-internal AD login, etc.

• User ID must be memorable. • Cannot just make up a new ID (e.g.,numeric) for new users.

• What to use? • Fully qualified, pre-existing e-mailaddress.

• Work address preferred over gmail,hotmail, etc.

4.2 Delegated administration

Who can create or modify whose ID and password?

• Each partner should nominate at least one person responsible for creating, managing other userson the portal.

• Limit what admin-level users can see to just their own organization.• The hosting organization can manage users across partner organizations.

4.3 Flexible authentication

How do users prove that it’s them on the portal login page?

• Simple solution: everybody provides their personal LDAP password.• Recommended: add a CAPTCHA:

– To all Internet-originating users (i.e., not on-premises/VPN staff).– Objective: block scripted attacks.

• If partner/users forget their password, offer a combination of CAPTCHA plus:

– Security questions, and/or– PIN sent to e-mail address of record, and/or– PIN sent to mobile phone (SMS).

• Consider OTP devices for staff who can manage other users.• If required, consider OTP or SMS/PIN as a 2nd factor for partner admins.


Slide Presentation

4.4 Onboarding process

• Staff onboarding new customers, create/designate admin users.• Admin users create new users within their own organizations.• Set all initial passwords to a random string.• New users get a random activation PIN via e-mail at first login attempt.• New users should:

– Read/accept an AUP document.– Enroll security questions.– Possibly provide mobile phone number.– Set their initial (non-random) password.

4.5 Update contact info

• Users should be able to update their own phone number, name, other identifying data.• Some changes should be approved by their partner-admin.• Other changes should only be available to the admin:

– Change of e-mail address (it’s the primary identifier).– Toggling the admin flag.– etc.

4.6 Terminations process

• Support staff should be able to create/modify/deactivate any non-staff user.• Partner-admins should be able to create/modify/deactivate any user in their own organization.• Termination processed as "disable now, delete later."• "Reactivate" process – for disabled but not deleted users – should be available to staff.• Optionally:

– Detect users with no recent logins (into main portal, not just IAM).– Send reminder e-mail: login or lose access.– If no login, disable account.

4.7 Periodic recertification

• At least annually and as often as quarterly, invite partner-admins to review a list of users in theirorganization.

• E-mail invitation and periodic reminders.• Checkboxes: keep or delete.• Password input/validation as electronic signature.• Automatically submit workflow requests to deactivate "delete" users.• Automatically deactivate users who have not been certified some time (N days) after the invitation to

review access.


Slide Presentation

4.8 Password change/reset

• Signed-on users can change their own password, regardless of how they authenticated (password,security questions, SMS/PIN, etc.).

• Partner-admins can reset passwords for others in their organization.• Staff can reset passwords for any non-staff user.• Enforce a central password complexity policy.• Do not allow password reuse.• Optionally, send users reminders to change passwords.

– Frequency: 90 or 180 days.– Reminders: 10, 5, 3, 2, 1 days before expiry.– Consequence of non-compliance: lock out account (likely orphan).

4.9 Reference implementation

• Hitachi ID can provide a pre-configured system with all of the features described in this presentation.• Pre-configured for a single LDAP back-end system.• Other data includes a regular feed of "valid, active" partner company IDs.• Optional: a list of well known public mail systems, to prevent users from enrolling this as their primary

ID.• Configuration changes primarily made by editing policy in XML document and via web UI.

4.10 Optional components

The Hitachi ID software is capable of much more than what is configured by default in the B2Breference implementation:

• Automated ID create/delete, via per-partner data feeds (for larger partners).• Self-enrollment, rather than partner-admin-requested.• Enroll using "social" identity (e.g., self-enrollment via Facebook, GMail, Live.com, etc. – using

OAuth).• Manage membership in security groups (request, approve, recertify, enforce SoD, etc.).• Authenticate into the portal via SAML (from large partners with many users).

5 Architecture


Slide Presentation

5.1 B2B IAM Portal Architecture

Extranet DMZ:

location 1

Firewall

Firewall

UserLaptop

UserLaptop

UserLaptop

Internet

3rd party app.

Directory 1

IAM server 1 Application 1

Load balancer 1

Directory 1

IAM server 1 Application 1

Load balancer 1

Extranet DMZ:

location 2

Multi-master architecture;

real-time data replication

5.2 Multi-master IAM

• Multiple servers can be configured in a peer-to-peer, replicated, multi-master (active/active)arrangement.

• Different nodes can be located in different geographic locations (e.g., geographical affinity to endusers).

• Data replication is handled at the application level:

– Encrypted (shared key).– Tolerant of high latency.– Bandwidth efficient.– Fault tolerant (multiple retry queues).

• Don’t forget to add:

– Load balancing (IP or DNS).– A multi-master directory infrastructure.


Slide Presentation

5.3 LDAP and other connectors

• The reference implementation is configured for a single LDAP directory.• Other directories and other systems/applications can be added using included connectors.• Can integrate via:

– SQL (Oracle, MSSQL, DB2/UDB, MySQL, etc.).– LDAP.– Web services.– Web scraping (for apps that have no API).– CLI integration.– More...

5.4 Portal with branding, localization

• UI is pure HTML• HTML can be modified via simple macros, that represent shared/repeated HTML markup.• Branding via CSS.• All text is translatable:

– Language file on filesystem.– Text editable as a table of language tags.– Can also adjust text interactively "in-app."

6 Wrap-up

6.1 Summary

• Vendor:Hitachi ID – a committed, stable, established IAM specialist.

• IAM Strategy:delegate create/support/delete to customer admins.

• Products:Hitachi ID Identity Manager and Hitachi ID Password Manager.

• Reference architecture:Included for minimal/no cost. Consulting to integrate and adjust.

6.2 Questions

• Technology?• Commercial terms?• Reference implementation?• Next steps?

hitachi-id.com

500, 1401 - 1 Street SE, Calgary AB Canada T2G 2J3 Tel: 1.403.233.0740 Fax: 1.403.233.0725 E-Mail: [email protected]

Date: 2018-06-14 | 2018-06-14 File: PRCS:pres

https://Hitachi-ID.com

1 Managing Portal Access - Hitachi ID...

Documents

Transcript of 1 Managing Portal Access - Hitachi ID...