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

Business Cases - Web/Mobile SSO Case Requirements

We will start a series focusing on the Centrify User Service and to give it the right context, just like we did a year ago with Server Suite we are basing this in a set of business requirements.

Here's a summary of the requirements:

Web and Mobile SSO
Our organization currently uses Salesforce, Office365, Google Apps, Sharepoint (internally), has Apache/Java (internally) and they need SSO;  some of these apps are SAML, WS-Fed, User/Password or may be using the Centrify on-premise app plugins.

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).  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.

Security Requirements
Confidentiality - no synchronization of personal identifiable information off premises; encryption in traffic and at rest is required.
Access Control - the security department wants to have the flexibility to set policies that allow to control access based on time/day, network or geographical location (to limit apps to be intranet accessible only, not via the web);
Step-up Auth - One-time-passwords (two-factor) should be an option for sensitive use cases.
Governance -   Entitlement management and separation of duties should be enforced.
Availability
Availability - As a global company, close to 100% uptime, geographical layout and redundancy are a most.

Infrastructure Requirements
Business Requirement - The IT organization wants to shift capital expense (capex) to operational costs (opex);
Self-Service - the solution should provide flexible self-service options to minimize calls to the help-desk.
Office 365 - all features (rich or web clients) should be supported, ideally without added infrastructure complexity.
Decrease VPN usage - ideally this solution should provide alternatives to VPNs for internal-only apps.
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.

Other Requirements
Project Management and Methodology - the PMO would like to use the same methodology (DEV-QA to PROD) for this project.
Marketing - Branding and imaging should be maintained.


Go to Planning Session I:  http://centrifying.blogspot.com/2014/12/business-cases-web-mobile-sso-planning.html

Basics: Centrify User Suite

Background

Centrify has two product lines.  Server Suite and User suite. With the release of Suite 2014.1, we are starting to see some synergy between product lines and since the blog has focused exclusively on server suite, we figured we need to expand, but first, let's explore this product.

What is Centrify User Suite?

Well, let's see:

• It's a cloud-based Identity Provider
• It provides access and SSO to on premise and cloud apps
• Provides Mobile Device, Application and Container Management
• It provides self-service capabilities (device enrollment, management, self-service password reset)
• Provides a catalog of over 2500 templates for fast publishing of Web, SaaS (SAML, WS-Fed, etc) and Mobile Apps.
• Provides Multi-factor Authentication
• Provides AD-based, Cloud-based or Mixed Identity
• Works with Active Directory in a non-intrusive (no directory duplication) and secure way
• Provides a policy engine for the directory
• Provides Role-Based Access for Application access and Privilege Management
• Provides multi-geography, shared or dedicated hosting
• Provides an interface that
• Provides access in rich (web) and mobile clients
• Provides tenants with their own publicly-rooted certification authority
• Provides access to apps can be via a self-service portal (provider-initiated) or application initiated.
• Extensible by way of an SDK, customizations and branding.
• Recognized by Gartner as a visionary in the 2014 IDaaS MQ.
• Continues to add capabilities at a near monthly rate

Where's the value?

In my opinion, the biggest value of user suite is that in the same spirit of server suite, for any organization with AD, provides the fastest, most efficient and secure way to adopt SaaS applications, it does it without breaking the bank and without aspiring to become the organization's directory of record.  The mobile, directory and hybrid identity and policy services are the cherry on top.

Here's what you don't need to do with user suite:

• Deal with servers in the DMZ
• Deal with understanding on premise federation technologies
• Deal with understanding app authentication or federation patterns
• Deal with publicly rooted certificates
• Pay for expensive MDM solutions
• Pay for 2-factor authentication solutions
• Worry about geographically located solutions
• Worry about language and branding
• Worry about having a split strategy for mobile devices

This translates to tighter control, time to market, added capabilities, etc.

What you must know and have:

• What are the different Cloud IdPs and their pros and cons.
• A policy for cloud-based access controls
• A plan for service availability

We'll explore topics related to cloud in Security Corner.

User Suite Tour

Labs and User Suite

Updated labs logo

We will keep things practical expect a lot of labs, howto's, etc.  We will be using Office365, Google Apps and Salesforce as our key apps given that they either provide a free or cheap version.  As we can find trial apps we will explore them.  As it relates to mobile, we will use iOS, Android and OS X.

Basics: What constitutes a cloud identity?

Hola!! from Panama City.  At Centrifying we are tasked to represent Centrify in the ISACA Latin America CACS 2014.
We had a chance to educate the attendees in the challenges and concepts of cloud identity and SaaS access controls security.

Background

This new series focuses on Identity as a Service (IdaaS).  As you probably know by now, Centrify has two product lines Server Suite and User Suite.  The first basic topic is to understand what constitutes a cloud identity.  At a basic level, the identity that supports a SaaS application can be as simple as a unique identifier and a password; However, that doesn't translate into a very valuable app.

So what's the problem with SaaS apps as it relates to Identity?

Since SaaS apps extend the IT boundaries beyond the on premises data center over the Internet the most basic issues are around timely provisioning.  Once a user leaves the company if the offboarding process is not timely and efficient, the organization is exposed to a potential data loss.  Unfortunately, just like the issue with the  heterogeneous datacenter, the solution sets today promote capability and process fragmentation and here's where Centrify can help.  Furthermore, let's explore the problem by at further length.

The typical cloud IdaaS providers may make you think that the issue is just Cloud Identity and SSO (federation), but the problem goes beyond that.  Let's explore some aspects:

• License assignment:  this topic impacts the bottom-line.  How does your process makes sure that the user is properly licensed (no more than what they need), and that licences are administered accordingly.  

  

  Timely license management has cost implications

• Role, Profile or Group management:  Depending on the application, entitlements determine what the user can do within the application. This is key for sound security.
   

  

  Salesforce provides access to different functions based on the user's profile

• Multi-factor Authentication (MFA) and 2-Step-verification:  These capabilities are increasingly a must because they are the foundation for different types of policies.  The recent consumer services data-breaches illustrate that need.

  

  MFA and 2-step verification are a must nowadays, the issue is - how to standardize.

• Policies:  Each SaaS provider has a different way to deal with policies.  Would it be nice to do it in a single management framework? and wouldn't it be nice if it's enforceable across all endpoints including mobile devices?

  

  Different SaaS providers provide different policy frameworks

• Support for Mobile Device Management (MDM) Mobile Application Management (MAM) and Mobile SSO:  This capability is also a must;  as phones and tablets become more powerful, mobile computing is a big tool in the information worker arsenal.

  

  MDM has become commoditized, MCM is looking for a standard, but MAM and Mobile SSO are growing

Is there a Unified Solution out there that is friendly to Active Directory?

So the question is - What if there's a solution out there that allows you to use an existing infrastructure (AD) to solve all these issues without the need of additional infrastructure or the need of complex Identity synchronization?   

YES!

That is what Centrify User Suite is all about! The next posts will focus on the service and 3 apps: Google Apps, Office 365 and Salesforce.  The first post will explore what Federation is and isn't.  Look for the Cloud-labeled articles.