The CalNet Iceberg - Identity and Access Management · The CalNet Iceberg ... [OpenIDM] Middleware...

The CalNet Iceberg

BerkeleyPersonRegistry

ADVCON

HCM SIS

Why does UC Berkeley do IAM Centrally?

02/25/15 | CalNet Roadmap ITLG

To make it easier for developers to do the right thing

•  Distributed application administrators are focused on delivering specific functionality.•  Access control can be a big job on its own. •  Widespread use of delivered access controls within applications can lead to identity

fragmentation which is less secure and less convenient.

Easier for Developers



To save time and money

•  Managing computing credentials wastes resources for applications.•  Managing multiple computing accounts wastes time for end users.•  Single sign on saves 30 seconds per day x 77000 people.

–  650 person hours per day

Save Time and Money



To remove barriers to collaboration

•  Collaboration is a global phenomenon.•  Research groups cross physical borders and institutional boundaries.•  An effective Identity Management strategy must provide mechanisms for secure, authentic

collaboration.

Collaboration



To enable self sufficiency for individuals

•  There is no model for IAM that requires hand-holding for individuals. •  Credential management, and attribute assertion must be automated and scalable.•  Individuals must have the tools to assert their own identities where and when they need to

to do their jobs or complete their studies and research.

Self Sufficiency



To provide continuous improvement

•  The private sector is leading the way with OAuth, Two factor and related technologies. •  Users have expectations about simplicity of access and assurances of privacy. •  An educated team of knowledgeable experts needs to continue to push what is possible

just to meet what is expected.

Continuous improvement

CalNet Challenges


Func0onal Enhancement

Founda0on Reinforcement

Succession Planning

CalNet Challenges

The CalNet Cookbook


CalNet provides the ingredients, recipes and cooking lessons to allow UC Berkeley technologists to create secure, effective and delicious Identity and Access Control solutions.

The CalNet Cookbook

Berkeley Person Registry May 2015

SIS Import Integra:on

September 2015

Guest Account Refactoring May 2016

Group Management August 2015

Group Distribu:on February 2016

CalAccess Enhancements August 2016

Creden:al Management

September 2015

CAS Authoriza:on March 2016

Mul: Factor Authen:ca:on October 2016

CalNet Roadmap 2015-2016


Iden0ty Management

Access Control

Authen0ca0on

CalNet Roadmap Overview




Iden0ty Management

Registry - Roadmap

Berkeley Person Registry


•  May 2015May 2015

Summary Value

•  Calculated Person Representa0on •  Merges aCributes from:

•  Student System •  HR System •  Alumni System

•  Extensible to addi0onal sources •  All data stored upstream of LDAP/AD

•  Good data enables good access control decisions

•  Flexible inbound and outbound data feeds to facilitate integra0ons

•  Crowd source data from authorita0ve sources outside of ERPs (office loca0ons)

Recipe: How to load departmental a.ributes into the central person directory.

Registry - Summary



• HCM • SIS • ADVCON

Systems of Record

• Flat File • DB View • Real Time

SoR Gateway • PostgreSQL • UI for par:al match

ID Match

• PostgreSQL • Extensible

Registry DB • OpenIDM • ASributes and Creden:als

Provisioning Engine

• LDAP • Ac:ve Directory • Kerberos • REST APIs

Directory Services

Registry – Data flow

Registry DB(master)

[PostgreSQL]

ID MatchEngine

[CalNet Match]

HR

SIS

ADVCON

LDAP

AD

Kerberos

Grouper

CalNetAdmin UI

Apps[Grails]

CalNetSelf Service

UI Apps[Grails]

Others(UCNetId, etc)

Others

ProvisioningEngine

[OpenIDM]

MiddlewareWeb Services, ESBs, Messaging, etc.

(Integration team and/or CalNet internal)(Not all lines drawn - Middleware cancommunicate with anything in diagram

depending on needs and laterdesign decisions.)

(Conduit for future real time data from SIS, UC Path, etc)

ReportingRegistry

(slave)[PostgreSQL]

UCB ProposedRegistry Architecture –With Tech ComponentsLast Modified: 01/16/2015 Campus

Apps

WorkflowEngine[Activiti]

[Apache Stack]

[REST]

[REST]

[REST]

SOR Gateway Service

[Groovy/Grails]

Real-TimeInterfaces

(Future-State SORs)

[Web Services/Messaging]



Registry - Architecture

Berkeley Person Registry Recipe


Iden0ty Management Load departmental attributes into LDAP

-  Example: Set access based on faculty lab assignments

-  This recipe will help you set up a data feed of department specific attributes from your local systems to the central person registry.

-  These attributes will then be available via central authorization mechanisms for making access control decisions

Registry – Recipe



September 2015



Iden0ty Management

SIS Import - Roadmap

SIS Import Integration


•  May 2015September 2015

Summary Value

•  Two Way SIS Integra0on •  Student Iden0ty informa0on in real

0me and batch •  UID return messages •  CAS Integra0on •  Iden0ty Crosswalk for HCM-‐SIS

Communica0on

•  Real 0me represents major improvement in user experience

•  Personal informa0on changed in HR reflected in SIS automa0cally

•  Loosely coupled integra0on paCern enables future func0onal enhancements

Recipe: Not applicable

SIS Import - Summary



September 2015




Iden0ty Management

Guest - Roadmap

Guest Account Refactoring


•  May 2015May 2016

Summary Value

•  Integrate Guest Accounts with Person Registry •  Treat Guest Account system as a

first class system of record •  Move guests out of their own

LDAP silo •  Requires enhanced Authoriza0on

by applica0ons

•  Make transi0on to and from guest status possible

•  Improved ability to manage user lifecycle through edge cases

Recipe: How to avoid duplicate accounts when early onboarding new faculty.

Guest - Summary

Guest Account Recipe


Iden0ty Management Avoid duplicate accounts when early onboarding faculty

-  Example: Faculty member needs access to CAS protected departmental applications to prepare for course instruction.

-  This recipe will help you get a guest account for a new faculty member who is not starting for several months.

-  By following this recipe you will be able to seamlessly migrate to a full employee account upon hiring.

Guest – Recipe



September 2015





Iden0ty Management

Access Control

Grouper - Roadmap

Group Management


•  May 2015August 2015

Summary Value

•  Improved Grouper user experience •  Automated group crea0on

•  Role based •  Student, Staff, Faculty

•  Department Code •  Academic Program •  Course/Sec0on

•  Non-‐technical users can manage group membership

•  Access control decisions in the hands of business owners

•  Allows the crea0on of dynamically updated calculated groups

•  Enables access control decisions based on centralized aCributes

Recipe: How to make an Ad Hoc group that only includes ac<ve employees.

Grouper - Summary

Group Management Recipe


Iden0ty Management

Access Control

Make an Ad Hoc group that only includes active employees.

-  Example: You want to define a group of people who can access your departmental application but only as long as those people are on payroll.

-  This recipe will explain how to create a compound group that includes members you add who are also active employees.

-  If they stop being an employee, they will be removed automatically.

Grouper - Recipe



September 2015






Iden0ty Management

Access Control

Group Distribution - Roadmap

Group Distribution


•  May 2015February 2016

Summary Value

•  Loading and documen0ng LDAP groups •  Loading and documen0ng AD groups •  Documenta0on of group based web

services •  Integra0on with other group stores

•  Make group informa0on available to consumer systems throughout campus

•  Provides an integra0on point for many vendor applica0ons

•  Provides consistent permissions across pla\orms (same group of people have access to a SharePoint group as a CASified webpage)

Recipe: How to consume group informa<on programma<cally for my applica<on.

Group Distribution - Summary

Group Distribution Recipe


Iden0ty Management

Access Control

Consume group information programmatically.

-  Example: You want to automatically provision accounts within a custom application at runtime based on membership in one or more groups.

-  This recipe will explain how query the members of a group from within your application code.

Group Distribution - Recipe



September 2015







Iden0ty Management

Access Control

CalAccess - Roadmap

CalAccess Enhancements


•  May 2015August 2016

Summary Value

•  Focus workflow endpoints on Grouper Groups

•  Documenta0on for managing results in Grouper

•  Workflow engine refinement •  Improved user interface

•  Ties group onboarding to business owner decisions

•  Ability to 0e decisions to automated de-‐provisioning logic

•  Makes CalAccess easier to integrate with applica0ons

Recipe: How to offload manual access control decisions to business owners using automated group loading workflow.

CalAccess - Summary

CalAccess Recipe


Iden0ty Management

Access Control

Offload manual access control decisions to business owners .

-  Example: Access to a departmental application is determined by the director. By tying access to a group and letting the director approve access requests to enter the group, decisions are placed in the business owner’s hands.

-  This recipe will explain how to configure CalAccess to populate groups based on an approval workflow.

-  Users can request access and data stewards can grant or deny requests.

CalAccess - Recipe



September 2015






September 2015



Iden0ty Management

Access Control

Authen0ca0on

Credentials - Roadmap

Credential Management


•  May 2015September 2015

Summary Value

•  Usernames and Passwords •  Updated User Experience using

OpenIDM 3.1 •  Self serve new user bootstrapping •  Self serve password reset strategy •  Improved synchroniza0on between

MIT and AD Kerberos

•  Improved user interface for crea0ng CalNet usernames and passwords

•  More efficient password reset op0ons for local and remote users

•  Windows and non-‐Windows passwords stay in sync beCer

•  Improved security by preven0ng Kerberos failover

Recipe: How to get a new password for a remote faculty member.

Credentials - Summary

Credential Management Recipe


Iden0ty Management

Access Control

Authen0ca0on

Get a new password for a remotely located researcher.

-  Example: A researcher in the field has her password compromised and must reset it remotely. She is issued a reset token sent to an external email address that has been confirmed as secure.

-  This recipe will describe the steps required to reset a password for a researcher who is unable to come to campus.

Credentials - Recipe



September 2015






September 2015




Iden0ty Management

Access Control

Authen0ca0on

CAS AuthZ - Roadmap

CAS Authorization


•  May 2015March 2016

Summary Value

•  CAS out of the box does only Authen0ca0on

•  isMemberOf query 0es CAS access to group membership

•  Only provides access to Staff, Student, Faculty by default (Flip the default to prohibit access to non-‐core popula0on unless otherwise indicated)

•  Provides a safety net for applica0on level access control

•  Defaults to fail safe for access control •  Service owners must explicitly

permit non-‐core users into their applica0ons

•  Automa0cally de-‐permits accounts based on role

Recipe: How do I make sure my applica<on is only accessible to current, ac<ve employees?

CAS AuthZ – Summary

CAS Authorization Recipe


Iden0ty Management

Access Control

Authen0ca0on

My CAS application is only accessible to current employees.

-  Example: An institutional application is made available to student workers via CAS. When they leave their position, they maintain valid CAS credentials as a student but should no longer have access to the employee application.

-  This recipe will describe how to configure your CAS service to limit access to people in a certain group.

CAS AuthZ - Recipe



September 2015






September 2015





Iden0ty Management

Access Control

Authen0ca0on

Multi Factor - Roadmap

Multi Factor Authentication


•  May 2015October 2016

Summary Value

•  Something you have + Something you know

•  Depends on funding and support •  Iden0fy which applica0ons require

addi0onal levels of security •  End of life CalNet Key

•  Reduces or prevents the use of phished creden0als

•  Improves security for the en0re university

•  Allows services to determine their level of assurance

Recipe: How do I protect my applica<on from access by phished creden<als?

Multi Factor - Summary

Multi Factor Recipe


Iden0ty Management

Access Control

Authen0ca0on

I need to protect my service from compromised passwords.

-  Example: Users can check their email with just a username and password. But in order to update their direct deposit information, they must use a second factor. This prevents stolen credentials from being used to redirect paychecks.

-  This recipe will describe how to require users to not only have a password, but also a second authentication factor like a cell phone or hardware token.

Multi Factor - Recipe



September 2015






September 2015





SIS

SIS SIS

SIS

SIS Iden0ty Management

Access Control

Authen0ca0on

SIS Impact on Roadmap

SIS: Timeline poten0ally impacted by Student Informa0on System Integra0on.

Date post:	01-Apr-2018
Category:	Documents
Upload:	volien
View:	221 times
Download:	1 times

The CalNet Iceberg - Identity and Access Management · The CalNet Iceberg ... [OpenIDM] Middleware...

Documents