Business Cases - Web-Mobile SSO Planning Session I - Global Settings

In a previous post, we discussed the requirements for the Web and Mobile SSO use case, and although our labs are aimed to help with testing or proofs of concepts, we typically address the planning.  Many of the topics in the requirements are huge (like o365 or GoogleApps migration), but we'll do the best we can to outline some of the key parts of planning.

Project Management and Methodology - the PMO would like to use the same methodology (DEV-QA to PROD) for this project.

What this means is that you need to have multiple cloud tenants a test and a production tenant.  Ideally, you will have a test environment that mimics your existing infrastructure.  My advice is that you use a rolling wave when it comes to IdaaS as well.  Scenarios like switching how people access your CRM (e.g. Salesforce) or ERP (e.g. Netsuite) can affect the bottom-line.  I won't be implementing this, but keep it in mind when implementing any cloud service.

Marketing - Branding and imaging should be maintained.

Organizations pay a lot of money to establish a brand identity;  your Cloud-based solutions should allow you to maintain that branding.  Centrify offers the ability to implement logos for the self-service portal, email invitations, mobile enrollment, etc. In addition, the main corporate color can be implemented as well.  This means that ahead of time you need to collect:

• The Pantone color code for your organization (main color) for the portal ribbon
• The corporate logo in several sizes:
• 137x35 to be used as the login image
• 160x36 to be used as the portal image

Business Requirement - The IT organization wants to shift capital expense (capex) to operational costs (opex)

From an accounting perspective, organizations prefer to shift costs to the capital expense category due to tax benefits;  in addition, clouds allow for commoditization of IT infrastructure services that in the traditional way would require space, power, cooling and personnel to support those solutions. The biggest example is email; HOWEVER, this has to be reconciled with security requirements.

Access to these applications has to be granted to Active Directory users, but there are instances in which partners need access as well (who won't have AD accounts).  

A lot is stated in this paragraph.  In the context of Centrify User Suite this means:

• Deployment of Cloud Connectors (CC):  CCs are Windows computers that use the service bus to talk to the Centrify Cloud Service and internally to Active Directory.  They provide many capabilities, but the main one is the avoidance of explicit replication of data to the cloud. When planning for Cloud Connectors
• Keep in mind the requirements:  As you add more users, keep in mind that the cloud connector's cache will grow.  At the time of this writing Cloud Connectors require a 64bit system with a multicore processor and 8GB of RAM with 4GB dedicated for the cache.
• Availability requirements:  You need at least two cloud connectors for basic load-balancing and fail-over.  If you are in a multi-national organization, placement of the cloud connectors should be based on the data-center location in the cloud.
• Internal placement:  Like any AD services, the closer you are to a global catalog domain controller the better.
• If using the Microsoft CA, make sure that you place the cloud connector near an issuing CA.
• Connectivity:  Although cloud connectors only perform OUTBOUND connections, there are certain domains that need to be reachable.  A list is here.
• Active Directory permissions:  Although no changes will be made to AD (in terms of schema extensions or services) the computer running the cloud connector will be able to access AD.  Permissions are required for this operation.  The instructions are here.
• Allowing MDM capabilities from Active Directory Users and Computers (ADUC) and Group Policy Management:  You must plan which administrators will provide helpdesk-assisted MDM capabilities using ADUC or which AD admins will be allowed to edit Mobile-related GPOs.
• Use of the Centrify Cloud Directory:  In those instances in which third parties (contractors, partners) need access to internal apps, but can't have an AD accounts, this will be the preferred method.

These users may access using rich clients (browser) or mobile devices (iOS/Android browser and mobile apps);  connections can be centralized via a portal, directly initiated or via intranet shortcuts.  In the case of Office365, users will continue to use their full clients (Outlook, Lync, etc) on their Windows and Mac workstations.

This paragraph also contains major implications.

• Mobile Access:  This means that corporate information may be accessed from devices that aren't under the control of IT.  Fortunately User Suite provides Mobile Device, Container and Application management for iOS and Android.
• iOS:  Managing iOS devices means that an APNS certificate needs to be configured in the cloud service.  In addition, if apps are purchased by corporate or devices are running in kiosk mode
• Portals, Direct Connections and Shortcuts:  Centrify provides the cloud portal for self-service of apps, mobile and AD/cloud directory; however it's possible that users may access apps directly, in that case, users will be redirected to be authenticated by Centrify if they don't have an active valid session.  Shortcuts can be deployed in the intranet as well.
• The topic of Office 365 migration is huge, however, from a rich client perspective, this means that the lowest version of office has to be Office 2010 with the latest and greatest service packs.

Availability - As a global company, close to 100% uptime, geographical layout and redundancy are a most.

As of this writing, Centrify relies on a robust infrastructure (Microsoft Azure) to provide high performance, high availability and redundancy.  Stats on the availability of the service can be viewed at http://www.centrify.com/cloud/service-status.asp 

Disjointed Namespace - The solution should accommodate for a different domain (for AD) than the business name (Internet DNS name).  It uses corp.contoso.com internally, vs. centrifying.net outside.

This is very common;  typically the Active Directory suffix of the UPN (user principal name) is different than the DNS suffix commonly used to do business  (typically the suffix of the email address);  this means that a company may do business as na.ad.company.com;  but users of that region use @na.company.com as the common suffix.  Centrify User Suite provides settings to accommodate this scenario.

Go to Session I Lab Videos:  http://centrifying.blogspot.com/2014/12/labs-web-mobile-sso-planning-session-i.html