Integration with Google - Patrick

Clarifications

Google is using the word migration in lieu of rollout because they are migrating existing user across platforms.

IdM Terms

CalnetID: the "friendly" login name for CAS; this is associated with an "unfriendly" employee ID
Scoped CalNetID: CalNetID@ berkeley.edu; it has @berkeley.edu appended to it and is a routeable email address
ePPN or eduPersonPrincipalName: InCommon/SAMLL2/Shibboleth credential for SSO authentication; at Berkeley, the scoped CalNetID is equivalent to ePPN
SSO: Single Sign On Authentication; once a user signs onto a SSO service, any other SSO service will not need authentication until session expires or browser is closed; user credentials will be shared
Kerberos:
Kerberos Principal: at Berkeley, the CalNetID / ePPN
Active Directory (AD): Windows-based login credential data store; at Berkeley, ePPN is not equivalent to Active Directory ID
LDAP:

Google Terms

Migration: Google is using the word migration in lieu of rollout because they are migrating existing user across platforms. It is mean to be a seamless transition of email rather than an introduction of a new service.

Box Terms

Questions from the IdM Team

What is the GMail migration schedule? -- Jeff this is complicated, so you will need to say why you need this for them to give you an effective answer; i.e. first migration date? all known target migration dates? target groups?
How will GMail team assign people logins that are their ePPNs.
- Jeff -- can you lay these out as options and not commentary
- It might be a good idea to only allow those who have Google accounts to have Box accounts.
- Alternately, maybe the CalMail folks can create email aliases for all the accounts that don't currently have a routable ePPN as well as changing the current email setup process as they have discussed to make the scoped CalNetID the only choice for email address. If that is accomplished our roll-out schedules don't really need to match any longer.

Questions to Sponsor

Should we purposely target the same or different departments for migration/rollout given its impact on Tier 1 support?

Integration Point Matrix

Integration Point	Owner	Assumptions	Default Answer (assumed direction)	Mitigation
Login ID	Dedra	IAM SC has final decision rights Expected to be approved Both services will use the same ID Dedra's team will represent this option to the committees Google has promised that email address for migrating parties will not change	scoped CalNetID	If not approved, use current processes and separate IDs. McG: - or -use a (cloud) id that is used for all services that require an email address as a user's ID.
Authentication Mechanism	Dedra	IAM SC has final decision rights Will minimally require vetting through 3 different committees Given former experience, expected to be approved Will require an enforcement policy (dog suit) We do not expect the final decision until after late February and will have to make decisions based on experience-to-date with committee Both services will follow the authentication rules contingent on whether they are high or low security services Dedra's team will represent this recomendation to the committees	We will get the tenor of the committees at the end of February, and make decsions on provisioning process	if not approved, build discrete provisioning process. McG: this will provide significant longer term support complications which will require rework.
Landing page - Description	Bill	All PS services will have general and consistent service descriptions information posted on technology.berkeley.edu	Describe all PS products on technology.berkeley.edu Provide links to more detailed description pages
Support Strategies	Bill	We will use a 5 tier support strategy as defined by SSC. This is a longer term goal that we must converge on dependent on implementation strategies.* We will adopt consistent strategies - as far as possible - approaches, tools to provide support to end-users. For deviations from a consistent approach, we should have a good reason. We will adopt the same support end-user entitlement policies across the services. We will adopt a hybrid support approach, that combines local departmental resources as tier 1 as an option to a fully shared tier 1 service desk.	We will adopt a consistent support strategy for PS services in the short term.	Each service will have its own approach which can be implemented more quickly, but probably result in greater confusion with the user population. Movement to the shared service center will be complicated also by service-driven support approaches.
Tier 0 support	Bill	All PS services will link to a Tier 0 support landing page on technology.berkeley.edu All PS services will use the same Tier 0 tools (listserves, knowledge bases, forums, social media??) to be extended to the user community.	Common tools and approaches will be adopted for services under the PS program. Link to FAQs and/or KB Access to community tool Links to social media??	Each service will have its own approach and toolset, which can be implemented more quickly, but probably result in greater confusion with the user population.
Tier 1 support	Bill	Each team will link to Tier 1 support personnel/queues from the tier 0 page/s on technology.berkeley.edu Tier 1 will require ticketing systems Tier 1 resources will be shared in the longer term and cross trained. Short term decisions will be made by each service on how to seed the tier-1 support function with skills.	For Units with IT leads, link to departmental support persons/queues For Units without IT leads, link to shared services center This approach requires separate landing pages based on the department (and perhaps within the department).
Tier 2&3 support	Bill	Definition of Tier 2&3 support will be driven by the Shared Service Center strategy. Their approach is Tier 2 will be service requests and Tier1 enabling functions. Tier 3 will be break-fix and enhancement related. Tier 2 support will be likely performed by the shared service center, while Tier 3 will be provided by each service team of service specialists. Common components or vendors used by each service will be addressed as Tier 4.	We will adopt a consistent support strategy for PS services in the short term.
Provisioning	Bill	For *new* users of the "cloud package", provisioning will be driven by a user-centric approach which provisions multiple services from one provisioning page (with the same ID) on technology.berkeley.edu. For *existing* mail users, email will be migrated in phases over the next year or so. Box provisioning will happen automatically, with the ID being the berkeley.edu email-address. This decision needs to be made pronto!* Box will be self-provisioned from technology.berkeley.edu GMail will be migrated and will not have self-provisioning. New students can self provision Box from MyBerkeleyApps MyBerkeleyApps has closed its development for Spring There will NOT be a single, joint provisioning or invitation to provision from Box and GMail Where fo we request volunteers?	A provisioning link for Box will be on technology.berkeley.edu and will redirect to box.berkeley.edu GMail will manually provision throughout its migration phases. (I am unsure on this one?)
Migration/Rollout - Timing	Bill	GMail is targeting a first phase migration for May 20 Box's rollout dates are not dependent on Google's migration phases, but could be more closely aligned as part of PS in general. Box's critical path is designed around completion of provisioning Box's rollout dates are dependent on release and testing of Box's new provisioning workflow + 5 weeks of local development; Box's provisioning software is due Feb 26	These two services will not rollout at the same time GMail's migration is dependent around date Box will rollout in Q2
Migration/Rollout - Audience	Bill	GMail is piloting through migration and are targeting current users Box and GMAIL will not target the same audience Box may choose a subset of students b/c they have less/no support needs and have little or no FERPA data	Target audiences TBD
Migration/Rollout - Tier 1 support	Bill	Tier 1 resources will not be shared or cross-trained Box and GMail are both assessing hybrid support strategies (part shared service center, part unit IT leads)	Box and GMail will approach shared services separately Box and GMail will approach unit IT leads separately
Deprovisioning	Bill	Gmail and Box will not synchronize deprovisioning processes GMail and Box and GMail will create separate deprovisioning processes	GMail will follow the current CalMail deprovisioning process Box will creates its own separate deprovisioning process
CalNet ID changes	Dedra	Given the interdependencies between the CalNetID and and account credentials, we will need a notification and update process for all effected services when CalNetId is changed	The timing on this can be in parallel bit should not slow down the authentication decisions
Security and Policy Training	Ann G	SPP will develop Data Classification standards in conjunction with the Data Proprietors SPP will develop a campus-wide training curriculum on those data classification standards	Leon Wong is developing the Data Classification system with Data Proprietors; this is expected to take 3-6 months Leon is developing interim definitions for Box's rollout Ann has verbally committed to the training curriculum in a Box meeting with Shel Ann has been reticent to own the training curriculum commitment since.
Terms and Conditions
User and Admin Guidelines

Joint milestones