Google Apps: Mastering Integration and Customization Scale your applications and projects onto the cloud with Google Apps
Médéric Morel Manuel Alves Pascal Cadet Pirmin Lemberger
BIRMINGHAM - MUMBAI
Google Apps: Mastering Integration and Customization Copyright © 2011 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews. Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book. Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: September 2011
Production Reference: 1070911
Published by Packt Publishing Ltd. Livery Place 35 Livery Street Birmingham B3 2PB, UK. ISBN 978-1-849692-16-8 www.packtpub.com
Cover Image by Vinayak Chittar (
[email protected])
Credits Authors Médéric Morel
Proofreader Aaron Nash
Manuel Alves Pascal Cadet Pirmin Lemberger Acquisition Editor Rashmi Phadnis Technical Editor Ajay Shanker Project Coordinator Alka Nayak
Indexer Monica Ajmera Mehta Graphics Nilesh Mohite Valentina D'silva Production Coordinator Shantanu Zagade Cover Work Shantanu Zagade
About the Authors Médéric Morel is Director of the practice “Enterprise Architecture” at Alcyonix. Manuel Alves is the Alcyonix Manager at Paris. Pirmin Lemberger is the Consultant in charge of R & D at Alcyonix. Pascal Cadet is Alcyonix Manager at Geneva. The authors would first of all like to thank their wives for their patience and continuous encouragement during the writing of the book. Their gratitude also goes to Yahya El Mir, Julien Mériaudeau, respectively CEO and chairman of the SQLI Group who sponsored the project. They thank their colleagues, friends, and customers who were kind enough to read the book and provide their feedback. In an alphabetical order: Thierry Albain, Arnaud Deslandes, Arnaud Damme, Gilles Godart, Olivier Larribe, Charles Le Gallic, David Macchioni, Jean-Luc Raffaelli, J.Patterson Waltz. Finally, special thanks go to Pascal Pignon, Regional Channel Manager for Southern Europe at Google who has consistently supported this project since the beginning and, in fact, made it possible.
www.PacktPub.com Support files, eBooks, discount offers and more
You might want to visit www.PacktPub.com for support files and downloads related to your book. Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at
[email protected] for more details. At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters and receive exclusive discounts and offers on Packt books and eBooks.
http://PacktLib.PacktPub.com
Do you need instant solutions to your IT questions? PacktLib is Packt’s online digital book library. Here, you can access, read and search across Packt’s entire library of books.
Why Subscribe?
• Fully searchable across every book published by Packt • Copy and paste, print and bookmark content • On demand and accessible via web browser
Free Access for Packt account holders
If you have an account with Packt at www.PacktPub.com, you can use this to access PacktLib today and view nine entirely free books. Simply use your login credentials for immediate access.
Table of Contents Preface
1
Part 1 – Cloud Computing in the Corporate IS Chapter 1: Google and the Basics of Cloud Computing A few words about Google Google Figures From online search to Enterprise computing Google and Cloud Computing Is Cloud Computing any different from ASP?
The nature of the players and billing Internal solution architecture and access to hardware resources
11
11 11 12 12 13
13 14
The different hosting modes
14
SaaS and software architectures
16
Traditional In-House hosting The Infrastructure as a Service—IaaS The Platform as a Service—PaaS The Software as a Service—SaaS Conclusion Centralized architectures The client-server architecture Web architectures Standalone architectures
Private or public cloud? Impact of the Cloud on the IS The IS in the 2000s The IS in the 2010s according to Google The economic impact of Cloud Computing A new economic approach to computing Reducing costs and investments
15 15 15 16 16 17 17 18 18
19 20 20 21 22 22 23
Table of Contents
Reduced cash requirements Improving cost visibility Should the Cloud and Google be adopted now? Summary
Chapter 2: Why Trust Google?
SaaS and data security SaaS opportunities What's Google's take? The multi-layer security strategy Google corporate security policies Organizational security Asset classification and control Personnel security Physical and environmental security Operational security Access control Systems development and maintenance Disaster recovery Regulatory compliance Security at the user level Data privacy The privacy principles that are implemented What data is collected? Use of personal information Cookies Connection data Geographic location
Technical means Availability of data and services How difficult is it to leave Google? Is it legal to use Google Apps? Summary
23 23 24 24
25
25 26 27 27 27 28 29 29 29 30 30 31 31 31 32 32 32 33
33 34 34 34
34 34 35 37 37
Part 2 – The Google Apps Platform Chapter 3: Communication Tools
A brief history of Gmail Gmail in detail How is Gmail different from traditional messaging tools? Nothing to set up on the client machine Constant improvements No more mail servers!
[ ii ]
45
45 46 46
46 46 47
Table of Contents State-of-the-art security tools A high level of reliability
47 48
General information
48
The main features
50
A search- and conversation-oriented GUI Spell-checking and formatting The auto-completion feature Import-export features Labels Searching for messages Filters Contact management Anti-spam and Antivirus Translation tools IMAP and POP access
48 49 50 50 50 52 52 53 54 55 56
Google Calendar in detail General information
57 57
Multi-calendar-oriented GUI Predefined calendars Import/export features
57 58 58
The main features
Creating calendars and events Defining reminders and notifications Sharing calendars and setting privacy levels Resource planning Publishing a calendar
58
58 59 60 62 63
Instant messaging with Google Talk Integration with Gmail
65 65
Standalone application Other ways to access Gmail and Google Calendar Mobile access
67 68 68
Audio and video Blocking a contact Instant translation Privacy
Gmail Google Calendar
66 66 66 67
68 69
Access using a fat client
70
The offline mode
71
Gmail Google Calendar
70 71
Gmail Google Calendar
72 72
Summary
72
[ iii ]
Table of Contents
Chapter 4: Collaboration Tools
Google Docs How does Google Docs differ from a conventional Office Suite? Word processing with Google Docs Creating and editing text documents Searching for documents Accessing document history Using Google Documents as attachments
73
73 73 74
74 75 76 76
Google Spreadsheets
77
Google Presentations
82
Google Drawing Sharing documents
83 83
Collaborating on a document Using templates Importing and exporting documents
86 88 88
Creation and editing of spreadsheets Tabs Formulas Formats and display rules Data validation Charts, drawings, and gadgets Creating forms
77 77 78 78 79 80 81
Creating, editing, and organizing a presentation Inserting images and videos Making a presentation
Sharing a document with authenticated users Sharing a document using a link Publishing a document as a web page
Text documents Spreadsheets Presentations
82 82 82
84 85 85
89 89 89
The offline mode DocVerse Google Sites Between a Wiki and a Content Management System One template for each use Creating pages
90 90 91 91 91 93
Defining access rights for collaboration Google Video Summary
95 95 96
The five types of pages The three categories of objects
[ iv ]
93 94
Table of Contents
Chapter 5: Security Tools
Overview The Message Center and the personal archive The Message Center The quarantine for spam The quarantine for infected messages The early detection quarantine The personal archive
Defining Options
Defining Whitelists Defining Blacklists Defining a threshold for the anti-spam filter
The main administration features Managing user accounts Creating users and organizations Default authorizations Defining user authorizations
97
97 99 99
100 100 101 101
102
102 102 102
103 103
103 104 104
Managing filters for Gmail
105
Managing archives Optimizing the security settings
111 112
The Antivirus filters The anti-spam filters Content filters Attachment filters Defining notifications
106 106 107 109 110
Adjusting the anti-spam filter Recovering a message from the quarantine
Summary
Chapter 6: Extending the Platform
Google Apps Marketplace Introduction Installing an application Google App Engine for business The deployment environment for GAE The sandbox The Java environment
The GAE services Meeting the constraints
112 112
112
113
113 113 115 116 118
118 119
120 121
The Datastore Quotas
A few examples of sites running on GAE Summary
[]
121 121
121 122
Table of Contents
Part 3 – Advanced Integration with the IS Chapter 7: Managing a Google Apps Domain Subscribing to Google Apps Which version to choose? Five steps to register for Google Apps Registering for Google Apps Confirming Domain ownership Managing user accounts Changing the MX-records to activate Gmail Activation of Postini services
127
127 127 128
128 129 130 130 131
Creating users and groups Manual creation Uploading a CSV file Creating a group Advanced methods
132 132 133 133 135
Adjusting domain settings Managing advanced elements Application settings Gmail Google Docs Google Talk Google Calendar Postini services Google Video Google Sites Synchronization with smartphones Additional services Summary
136 136 137 137 138 138 138 139 139 139 139 140 140
The provisioning API The Google Apps Directory Sync tool The Google Apps Provisioning Toolkit Activation of user-managed groups
Chapter 8: Federated Identity and SSO The SSO issues The SAML standard The SAML concepts
Use case: IdP-initiated Web SSO Use case: SP-initiated Web SSO
An implementation example: Shibboleth Delegation of authentication for Google Apps Workflow with Google Apps [ vi ]
135 135 135 135
141
141 143 143
145 146
146 148 148
Table of Contents
Settings in the administration console Shibboleth configuration Describing the SP and the SAML binding Specifying the SAML profile Specifying which attributes to transmit
Strong authentication with Google Apps Integrating Google Apps with an Enterprise SSO The Kerberos protocol Setting up Shibboleth for Kerberos Google Apps as an ID provider with OpenID Introduction to OpenID OpenID and Google Apps Summary
Chapter 9: Advanced Integration
Integration modes Accessing Google Apps from a third-party application: APIs APIs for application management Calendar Data API Contacts Data API Documents List Data API Sites Data API Spreadsheets Data API
APIs for domain management
150 151
151 151 151
151 153 153 154 155 155 156 158
159
159 160 161
161 161 162 162 162
162
Domain Shared Contacts API Email Migration API Email Settings API Provisioning API Reporting API User Profiles API
162 162 162 163 163 163
The Secure Data Connector The workflow of a SDC call Setting up an SDC
163 163 165
Running custom code on Google App Engine Inserting Google Apps gadgets in a portal Google storage Summary
166 167 168 169
Activation in the console Local configuration of the SDC
Chapter 10: Google "Workstation"
Accessing your Information System The user desktop Mobile devices Google's offering [ vii ]
165 165
171
171 172 172 174
Table of Contents
Chrome OS and the user desktop The Chrome web browser The graphical interface Security and reliability Performance Miscellaneous features
The Chrome OS operating system The graphical interface Performance
Android and mobile devices Main features Competitive advantages Summary
Chapter 11: Third-Party Extensions Convertigo Introduction
Enterprise mashups Convertigo solutions
174 175
175 176 176 177
178
179 179
179 180 180 181
183
183 183
183 184
Example use cases RunMyProcess Introduction Example use cases
184 187 187 188
Cordys Introduction Example use cases Summary
190 190 191 191
Case 1: SaaS workflow Case 2: SaaS synchronization Case 3: Application gadget
188 188 189
Part 4 – Managing a Migration Project to Google Apps Chapter 12: Choosing a Migration Method Identifying the company profile Size of the organization Geographic dispersion Targeting the appropriate population Existing mail Expressing requirements Functional requirements Non-functional requirements The migration strategy Projects, phases, and strategies
[ viii ]
197
197 197 198 198 199 200 200 201 201 201
Table of Contents
The elementary phases
202
The five types of strategies
204
Which strategy for which kind of organization?
206
Performing the preliminary study Designing a pilot Training users Setting up User Support Setting up a rollback plan Performing advanced integration Performing the migration
202 202 202 203 203 203 204
"Flash" strategy "Do It Yourself" strategy "Light" strategy "Standard" strategy "Advanced" strategy
Organization of Type 1 (OT1) Organization of Type 2 (OT2) Organization of Type 3 (OT3) Organization of Type 4 (OT4) Organization of Type 5 (OT5) Organization of Type 6 (OT6) Organization of Type 7 (OT7) Organization of Type 8 (OT8) Conclusion
Summary
204 205 205 205 206 206 206 207 207 207 208 208 209 209
210
Chapter 13: The Pilot Project
Why a pilot project? The issues Scheduling Defining a scope Choosing the applications Choosing pilot users Extending the scope The user-identity lifecycle Managing external mailing lists Access channels The authentication mechanism Transferring archives The TCO of the target solution The rollback and reversibility mechanisms Implementing the pilot project Signing up for a Google Apps account Choosing a domain name Choosing a version
[ ix ]
211
211 211 212 212 213 214 215 215 215 216 216 216 217 218 218 218
218 219
Table of Contents
Adding users to Google Apps Enabling and configuring the Google Apps services Dual-delivery via the Enterprise mail server Dual-delivery via Google Enhancing Gmail and Google Calendar
Evaluating the results of the pilot project Bringing support to users Evaluating the results Summary
Chapter 14: Performing the Migration The steps of the migration Data transfer Data transfer checklist
219 220
220 221 222
222 222 225 227
229
229 230
230
Microsoft Exchange Environment Administrator tools User tools Lotus Notes environment Generic tools IMAP method Alternative solutions Summary
231 231 233 235 237 237 239 239
Index
241
[]
Preface The Google Apps platform has been available for three years now and to this day it remains one of the most significant offerings in the domain of Cloud Computing. In the beginning, the offer was focused mainly on the messaging and calendar tools but it quickly gained momentum and now it covers most features one can expect from an office suite. Its use within corporate information systems is becoming increasingly popular and over 3 million companies are using it worldwide, ranging from the small businesses to multinational companies and administrations. The SQLI Group was among the pioneering companies, adopting the Google Apps as early as 2008. The set of services was soon recognized as a great collaboration tool among SQLI collaborators. This book summarizes the experience gathered by the authors as well as the feedback gained from numerous integration projects led by SQLI with different customers. This book touches upon both practical issues regarding the implementation of Google Apps and more theoretical concerns like the impact of Cloud Computing on the IT environment. The major technical questions that will be raised when deploying a Cloud Computing solution are addressed as well, especially those regarding integration with an existing identity management system.
Who should read this book?
This book is intended for anyone who will take part in the process of adopting or deploying the Google Apps solution in a professional setting. More specifically, this book is for: •
Senior executives who would like to understand what is at stake on the economic level and which issues are related to implementation of a Cloud Computing solution in their own company.
•
Project managers, who will get acquainted with the concepts and the specific vocabulary used during such a project.
Preface
•
Architects and developers, who will find useful technical guidance and recommendations that were gathered over the course of numerous projects. They will find many valuable hints on how to integrate Google Apps more closely in their own IT infrastructure.
•
Regular users who will find useful tips to make their lives easier and increase their productivity.
How to read this book
This book is split into four parts that are mostly independent from one another and can thus be read in any order. The reader who is in a hurry and is already familiar with the subject can therefore quickly jump to the section that is of direct relevance to him or her. The more patient reader will benefit from reading the Part 1 sets the scene and covers the basics of Cloud Computing and its consequences for the IT Department. The following figure illustrates how the book is organized:
2 Communication tools
Collaboration tools
Security Extending the platform tools
1
3
Cloud computing
Administration
Identity management Data security
Advanced integration Impact on IT department Analysis
Test
Metodology
Pilot Pilot project Migration
The Google Apps Context
[]
Desktop and extentions
Preface
Part 1 introduces the concepts of Cloud Computing and its various incarnations: IaaS, PaaS, and SaaS. Security and privacy issues are also touched upon. Senior executives are more likely to be interested in this section. Part 2 covers the various Google Apps services and applications as well as their most common use cases. It is mostly targeted at end users. Part 3 deals with integrating Google Apps with the rest of the IT environment. It includes an introduction to the administration tools and third-party solutions. This part is more likely to be of interest to technical architects and system administrators. Part 4 deals with implementing a migration to Google Apps. Project management issues are discussed, as is the experimental phase during which a pilot project is run. Finally, the implementation of the actual migration is covered. Various migration methods are discussed, depending on what the original mail platform is. This part is primarily for project managers and technical architects.
What this book covers
Chapter 1, Google and the Basics of Cloud Computing, begins with the basics of Cloud Computing. It discusses various hosting solutions and it concludes with an impact analysis of Cloud Computing on the future of the IS. Chapter 2, Why Trust Google?, presents Google's security-related issues and discusses solutions to deal with them. The security issues listed are security against data theft, non-disclosure of data to third parties, and guarantees with data availability. Chapter 3, Communication Tools, gives critical descriptions of Gmail and Google Calendar. The chapter then discusses high level of integration of these tools, which is precisely one of the main strengths of the Google Apps solution. Chapter 4, Collaboration Tools, presents the Google Apps collaboration tools and discuss how it differs from a traditional office suite and what advantages it offers for collaborative work. The discussion includes Google Docs, Google Sites, and Google video sharing tool. Chapter 5, Security Tools, discusses the security tools that come with Google Apps. The first section provides an overview of the main security components like the antivirus filters, the spam filters, filter rules, the quarantine for suspicious messages, and the archiving facility. Then the chapter describes the Message Center. The final section describes in detail the main tasks of a Google Apps domain administrator. Chapter 6, Extending the Platform, presents two different ways to extend the Google Apps platform. First, using the Google Marketplace, and second by using the Google Apps Engine. []
Preface
Chapter 7, Managing a Google Apps Domain, starts by explaining how to sign up and activate a Google Apps subscription. Next, administration tasks like managing user accounts, key settings of a Google Apps domain, and various advanced settings will be discussed. Chapter 8, Federated Identity and SSO, begins with a discussion of federation of identity and other security realms. The chapter then moves to the basic concepts of the SAML standard and using a local ID repository for authenticating. Chapter 9, Advanced Integration, discusses ways to integrate Google Apps in an enterprise IS. The different modes of integration we will discuss are: the Google Apps APIs, the Secure Data Connector, the Google Apps Engine, and widgets. Chapter 10, Google "Workstation", will cover Google's solutions for user desktop and experience, using Google Chrome as a workstation. Next, we will discuss Android and Chrome OS. Chapter 11, Third-party Extensions, discusses the third-party applications or extensions that are often the best choice when performing advanced integration of the Google Apps into the IS. Chapter 12, Choosing a Migration Method, aims to present various migration strategies to the Google Apps. The first section of this chapter describes a number of technical and organizational criteria used to characterize a company. Five strategies are selected and described in detail. Finally, we examine eight typical types of companies and propose strategies for them. Chapter 13, The Pilot Project, discusses a "Pilot Project" that usually takes place before the complete migration and presents the principal issues related to this pilot project. The issues discussed are organizational matters and its implementation. The chapter concludes with a proposal for evaluating the results of this experimental phase. Chapter 14, Performing the Migration, is dedicated to data transfer as it is one of the major hurdles in migrations. Separate sections are dedicated to Microsoft Exchange and IBM Lotus Notes.
Conventions
In this book, you will find a number of styles of text that distinguish between different kinds of information. Here are some examples of these styles, and an explanation of their meaning. Code words in text are shown as follows: "The file name is relying-party.xml."
[]
Preface
New terms and important words are shown in bold. Words that you see on the screen, in menus or dialog boxes for example, appear in the text like this: "Enabling and adjusting settings of the authentication delegation is performed using the Advanced tools in the Google Apps console." Warnings or important notes appear in a box like this.
Tips and tricks appear like this.
Reader feedback
Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of. To send us general feedback, simply send an e-mail to
[email protected], and mention the book title via the subject of your message. If there is a book that you need and would like to see us publish, please send us a note in the SUGGEST A TITLE form on www.packtpub.com or e-mail suggest@ packtpub.com. If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide on www.packtpub.com/authors.
Customer support
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
[]
Preface
Errata
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you would report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub. com/support, selecting your book, clicking on the errata submission form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded on our website, or added to any list of existing errata, under the Errata section of that title. Any existing errata can be viewed by selecting your title from http://www.packtpub.com/support.
Piracy
Piracy of copyright material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works, in any form, on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy. Please contact us at
[email protected] with a link to the suspected pirated material. We appreciate your help in protecting our authors, and our ability to bring you valuable content.
Questions
You can contact us at
[email protected] if you are having a problem with any aspect of the book, and we will do our best to address it.
[]
Part 1 Cloud Computing in the Corporate IS Google and the Basics of Cloud Computing Why Trust Google?
Cloud Computing in the Corporate IS The purpose of Part 1 is to explain the Cloud Computing context and to introduce the related issues regarding a company's IS and IT organization. Cloud Computing is a relatively recent phenomenon that is progressively making an entrance in more and more organizations. We present an overview of these emerging technologies along with their various incarnations: IaaS, PaaS, and Saas. Adopting Cloud Computing, or more specifically Google Apps, poses new issues in various domains such as data security, privacy, and reversibility to an existing situation. We shall discuss the impacts of deploying Google Apps companywide. Part 1, more so than the rest of the book, is intended for senior executives. It will also be of some interest to business executives who would like to grasp the ins and outs of Cloud Computing and Google Apps. Topics addressed include: The Basics of Cloud Computing (Chapter 1): This chapter discusses the main concepts of Cloud Computing, the economic impact, and Google's vision of the evolution of the IS in the 2010s. Why Trust Google? (Chapter 2): This chapter describes the new risks implied by the Cloud Computing model and how Google handles them.
Google and the Basics of Cloud Computing This chapter discusses the basics of Cloud Computing and its various incarnations: IaaS, PaaS, and SaaS. After a quick presentation of the Google platform (Part 2 is entirely devoted to this subject) the main hosting solutions are presented together with the various categories of application architecture. The chapter concludes with an impact analysis of Cloud Computing on the future of the IS. A short description of Google's enterprise services is provided as well.
A few words about Google
Google is a relatively recent player in the IT world. The company was founded in 1998 by two students from Stanford: Larry Page and Sergey Brin. It is obviously best known for its ubiquitous search engine that left nearly all its competitors far behind (who remembers Infoseek or Altavista today?), which allowed for an exponential growth of the company through online advertising. Google is also recognized for its extremely strong innovation policy, which allows the company to continuously offer new features.
Google Figures
Here are a few figures that give an idea of the weight of Google in today's IT world: • •
25,000 employees, half of whom perform R&D activities; this is one of the largest in the IT world More than 3 million servers (estimation from Gartner)
�� ���� IaaS : Infrastructure as a Service; PaaS : Platform as a Service; SaaS : Software as a Service. �� ������������ The company �������������� was worth 210 �������� billion ���������������� dollars in 2008 �������� (source ����������� Wikipedia).
Google and the Basics of Cloud Computing
•
1 billion search requests every day.
•
1.7 billion users of its search engine around the world
•
The amount of information contained in the Library of the Congress is indexed every 4 hours
The unique position of Google in the search engine market is what makes the company a giant, regarding both the number of its users as well as the size of its data center infrastructure which, at this point, is already the largest in the world. The obvious question is: why should a player in mainstream computing like Google invest so heavily in the market of enterprise computing?
From online search to Enterprise computing
The answer to the previous question is actually quite simple: considering the huge infrastructure that Google has set up for its search engine, you quickly realize that its hardware and software resources are extremely well consolidated and that this allows Google to offer the lowest costs for processing and storing data. This particular position, combined with an aggressive innovation policy, makes it possible for Google to enter new markets with both extremely low prices and original solutions that their competitors will have a hard time matching in the foreseeable future.
Google and Cloud Computing
The "Cloud" most often refers to the Internet seen as the network of all networks. Cloud Computing is a new and delocalized means that uses the Internet for both designing computing resources and consuming them. It should be realized that using the Internet to access those resources is a major change. Understood properly, the Internet is an abstraction that designates a worldwide interconnection of computing resources. With Cloud Computing, everything happens as if computing resources were not localized geographically anymore. Moreover, users themselves adopt an ever-more itinerant way of working and therefore they would like to access information and applications through many different terminals, whether fixed or mobile, and from anywhere: at home, in a cyber cafe, in train stations, airports, and even within the company's offices!
[ 12 ]
Chapter 1
The abstraction is indeed not only with respect to geography, but also with respect to technical infrastructure. Most Cloud Computing players (like Google, Amazon, eBay, and Salesforce) keep their technical infrastructure and their applications secret. There are two main reasons for these secrecy habits. The first one is obvious and is related to the security of platforms that are open to the Internet. They are inherently more vulnerable to attacks than closed platforms. The second is related to the new architectures that are being set up. These differ notably from the more classical architectures. Therefore, companies investing heavily in such infrastructure will obviously want to keep secret their main competitive advantage. Setting up such a large-scale distributed architecture constitutes a very high barrier that competitors in the same market will have to overcome. Another important point that characterizes Cloud Computing is its new billing model. Customers are now billed "on demand", which means that they will pay only for those resources that they actually use. The costs related with producing those services and maintaining or expanding the associated hardware and software architecture to meet the demand, are now entirely on the side of the service supplier. In summary, we can say that Cloud Computing is a new mode for delivering and consuming computing resources. These are delivered as services that can be used seamlessly from anywhere, because they use only the most basic standards of the Internet (TCP-IP, HTTP/HTTPS).
Is Cloud Computing any different from ASP?
The outsourcing of computing resources to specialized providers is, by itself, not a novel idea. It has been applied for many years under the name "ASP", which stands for "Application Service Provider". But looking more closely, you realize that ASP and Cloud Computing are really two very different approaches to outsourcing. Now we'll look at why.
The nature of the players and billing
ASP providers were historically hosting providers that offered an alternative to in-house hosting to their customer. In this approach, the ASP offer the use of applications built by other vendors (for example, hosting of a MS Exchange or IBM Notes email solution for the larger telecom companies). This new separation of responsibilities between the software designer on one hand, and the company in charge of the production on the other, necessarily induces complications such as upgrading to the latest version, providing patches, and resolution of incidents. It also weakens the autonomy of the customer. Moreover, when a vendor claims to provide a cloud version of an existing solution, you should be extremely cautious. [ 13 ]
Google and the Basics of Cloud Computing
Very few of them actually have the needed expertise and the scale that could allow them to offer low operating costs. Most of the time, such claims are not much more than a "cosmetic operation" cooked up by the marketing service to boost sales of existing software. In ASP mode, the customer usually pays for a package and later adds options when the demand for storage capacity increases. Cloud providers are pure players that offer their services in a hosted mode. They are simultaneously vendor and provider of their own solutions (for example Google Apps, SalesForce, Amazon, AWS). In general, there is no such concept as a version of the deployed software. Moreover, adding features happens seamlessly and continuously for the customer, unlike traditional software, which evolves stepwise. Billing is on a pay per use basis and it is therefore quite easy to change those resources (and hence costs) without the hassle of renegotiating a contract.
Internal solution architecture and access to hardware resources
The most common use of ASP is the deployment of a standard edition of some software on hardware dedicated to a single client. In this approach, each client has its own dedicated servers hosted by its ASP provider. At first glance, it might seem reassuring to keep separate resources for different customers. However, this automatically leads to poor equipment usage, significant additional costs, and low flexibility when the traffic load and the need for processing power suddenly increase. Moreover, some applications are not compatible with cluster deployment and don't take full advantage of such a topology. This limits their processing capacity. In Cloud mode, there is a thorough separation between an application and the hardware on which it runs. Customers now buy a certain amount of processing power, a number of accounts, or some storage space rather than dedicated servers. To implement this, the inner architecture of the solution must have been designed properly. This implies that an application should be able to leverage any additional processing capacity. Moreover, the application should also be designed from the start to allow managing all customers on a single platform. This is often referred to as a "multi-tenant" architecture. As already mentioned, this explains why only new players, who have developed applications specifically for this model, will be competitive in this market.
The different hosting modes
To analyze the various hosting modes, we will categorize computing resources into four distinct layers:
[ 14 ]
Chapter 1
•
The hardware: This includes technical premises (white rooms, data centers), servers and networking equipment such as routers, proxies, or firewalls.
•
The middleware: This includes essential software components that are necessary for running applications efficiently. Databases, application servers, and EAI belong to this category.
•
Software: In this category, we have business applications such as ERPs, customer relation management (CRM) tools, or messaging tools. Most often, these applications reside on a platform that includes one or more middleware components.
•
Operational resources: These include human resources and processes that handle IT operations. All common operations on a product platform such as deployment, upgrading, backup, and restoration belong here.
Now let's look at the four main hosting modes that we need to distinguish.
Traditional In-House hosting
In this mode, which is often referred to as "on-premise", a company manages all the components of its applications directly. It owns its server premises where all equipment running the middleware and the applications is installed. Local teams are in charge of daily operations and deployment.
The Infrastructure as a Service—IaaS
IaaS is an implementation of the Cloud Computing services on the lower layers of the IS. It allows renting processing units and storage capacity on demand. IaaS implies that the middleware and IT operations remain under the responsibility of the company that uses the IaaS.
The Platform as a Service—PaaS
PaaS can be seen as an extension to IaaS that goes beyond the rental of hardware. Namely, it includes middleware elements such as databases and application servers. PaaS can be used for instance by a traditional software vendor who would like to propose its products in SaaS mode. PaaS can also be used to run internal applications, by which we mean developed in-house. Unlike IaaS, the middleware is now under the responsibility of the service provider. Software and IT operations both remain under the control of the company that buys the services.
[ 15 ]
Google and the Basics of Cloud Computing
The Software as a Service—SaaS
This is the most advanced version of Cloud Computing. It offers software packages as services rather than as traditional executable software. There is a profound difference between SaaS and classical software. SaaS is nothing less than a set of ready to use services that requires no installation and no maintenance whatsoever for the company that uses them. This constitutes a radical change in the way a company operates its IT resources.
Conclusion
A wide range of hosting modes for enterprise applications is currently available. The general trend, however, is towards outsourcing of computing resources and it is fair to say that Cloud Computing largely contributes to this movement. The following figure recaps the various hosting modes and areas of responsibilities that follow: Servers
Middleware
Software
Operations
On-premise
laaS
PaaS
SaaS
Internal
Cloud
SaaS and software architectures
Before we go any further in our study of SaaS solutions, let's recall some basic facts concerning enterprise software architecture. The SaaS model is actually not suited for all architectures and you should be aware of the limits that apply when SaaS is used jointly with older architectures. [ 16 ]
Chapter 1
Centralized architectures
Centralized architectures are the most ancient architectures used in ISs. They are based on the simple principle of a passive terminal connected to a central system through the network. The latter manages absolutely everything, the session, the user interface, the business processing, and the storage of data. Two types of centralized architectures can currently be found in companies. On one hand, there are mainframes and machines such IBM's AS 400s. On the other, there are virtualization systems for the desktop, like Citrix or VNC. The following figure illustrates this kind of architecture:
LAN Connected protocol Passive terminal
Centralized architecture Mainframe
Centralized architectures are definitely not compatible with the SaaS approach for several reasons. First, they don't rely on modern and open standards. Next, they require permanent connections. Finally, they are not built on the server side using flexible, multi-tenant architectures.
The client-server architecture
Client-server architectures were massively deployed during the 90s, when relational databases and desktop computers became available. They are all based on client software (called the thick client) installed on the user's desktop and permanently connected to a database through a local network. The following figure illustrates this kind of architecture: CS architecture
LAN Windows/Mac OS desktop
Connected protocol database
The client-server architecture isn't compatible with SaaS either. Here is why: •
Using a permanent connection is a bottleneck on a resource that is actually critical for any server side application
•
Using a thick client implies many issues related to its deployment (installation, upgrade) as well as a strong dependency on the desktop [ 17 ]
Google and the Basics of Cloud Computing
•
The protocols for accessing databases are all proprietary and will be blocked by firewalls
Web architectures
Web architectures rely mainly on a web browser (which is by now available on any operating system) and a set of standards like HTTP and HTML to access web applications. These protocols have many advantages, including standardization. They allow a better use of networks and server-side resources when compared to connected and proprietary protocols used by client-server architectures. The disconnected nature of the HTTP protocol implies less resource consumption than that required for maintaining a permanent connection in the case of client-server architecture. A single server can thus handle the requests from a large number of users.
WAN Web
Web architecture
Diconnected protocol Server Web
Web architectures are well-adapted to SaaS constraints and nearly all SaaS applications rely on this kind of architecture, whose flexibility and openness allow quick deployments with low coupling to the desktop system.
Standalone architectures
By standalone architectures, we mean applications that were designed specifically for the desktop, running Windows most of the time and sometimes Mac OS. They don't use any network connections. These applications run autonomously on the desktop. Business productivity tools like Microsoft's Word, Excel, PowerPoint or MS Project, all belong to this category.
Internet Windows / Mac OS Desktop
No network access
[ 18 ]
Standalone
Chapter 1
So far, these applications have resisted the wave of web architectures and thus, logically, the SaaS model as well. They indeed require a level of usability that HTML pages have had a hard time matching. The situation is however about to change for several reasons: •
The upcoming version of HTML (version 5) will allow designing interfaces that are as sophisticated as those traditionally designed for Windows or Mac OS desktop applications.
•
The recent availability of the Google Apps suite has drastically changed the situation in the office tools market. These had actually changed very little over the preceding years. The historical dominance of Microsoft's Office suite is now likely to be challenged in the near future. Google has the means to offer very low costs and unique collaborative features.
•
The number of companies that try to greatly reduce the cost of their IS, their desktops, and their office suites is increasing exponentially.
Private or public cloud?
A "private cloud" refers to the application of some cloud computing technologies within a given company. The wording first appeared when some companies decided to reuse internally the methods and the tools of cloud computing. In fact, many IT specialists consider that, strictly speaking, this wording is misleading or even meaningless. The delocalization of computing resources is what really makes the essence of Cloud Computing. In such conditions, referring to a private cloud is simply an oxymoron. Moreover, a central idea of the cloud is that each customer pays only for the resources that were really consumed which, here again, loses its relevance in the case where the services are hosted on-premise. One last point: it should be clear that the robustness of the datacenters, like those of Google, largely stems from their size and their geographical spread. Few organizations, whether public or private, can rely on such large-scale deployments. But these scale effects are precisely the primary reason for the benefits of Cloud Computing and they also favor optimal energy consumption.
[ 19 ]
Google and the Basics of Cloud Computing
Despite the semantic criticisms that can be made regarding the relevance of the private cloud concept, it is nonetheless true that many companies are currently interested in high availability and scalability, and that these two features precisely characterize cloud computing. Current solutions are most often based on expensive implementations of clustering. They are often complicated to deploy and far from satisfactory. Henceforth, the new platforms use virtualization on a scale that was unknown until recently. This opens new horizons to IT management and it is therefore easy to understand that companies now try to master these technologies for in-house use. The IT departments that position themselves as internal service providers have adopted the "private cloud" wording. It should be clear though, that this is really just another form of the traditional virtualization, rather than genuine Cloud Computing. In the end, the private cloud is best understood as a marketing concept, rather than a technology or a real IT concept. Except for larger companies, it is unlikely for a "private cloud" to reach the same consolidation level as the public clouds. However, the "private cloud" can be a real opportunity for IT departments who wish to virtualize business applications for which no public offer is currently available.
Impact of the Cloud on the IS
The upcoming Cloud Computing tools and new products such as the Google Apps are going to shape and accelerate the evolution of enterprise IS. To illustrate this evolution, let's examine the present situation for most IS.
The IS in the 2000s
Information systems are structured around three distinct layers: •
The first layer is the infrastructure, the foundation underlying the IS that is used by all components. This foundation includes at least the networking equipment, the servers, and shared elements such as directories, proxies, or firewalls.
•
The second includes applications (ERP, e-commerce, supply-chain, CRM, groupware, portals…). These are most often organized into autonomous silos and communicate little with each other.
•
The third includes the user desktop. This has changed very little over the past 20 years and is still based on a classical PS running Windows.
The following figure illustrates a typical IS with its PC desktops, business applications, and the foundations:
[ 20 ]
Chapter 1
Windows desktops
GUI
GUI GUI
GUI GUI
GUI GUI
Processing
Processing
Processing
Processing
Data
Data
Data
Data
ERP
CRM
E-Commerce
Collaboration
Infrastructure
The IS in the 2010s according to Google
Cloud Computing actors imagine a new landscape in computing and information systems that should be more flexible and at the same time more agile. Google's vision is based on generalizing web technologies to business applications, to the usual office productivity tools (spreadsheets, word processing), fueled by a massive adoption of mobile technologies. Once most applications are web apps, it becomes legitimate to question the Windows-based PC desktop that we have been accustomed to for over 20 years now. This old paradigm is indeed challenged by an emerging model: a lightweight desktop built around a single application, namely: the browser. The economic stakes here are enormous because the desktop is a major expenditure for many IT departments. The following figure illustrates Google's vision for the 2010s IS. Some application silos are simply outsourced in the cloud, especially for commodities such as email, calendaring, collaborative portals, and office tools. For the time being, the more specialized business applications still remain in-house. The classical desktop such as PC/Windows or Mac OS is clearly declining, and is limited to launching older client-server applications or standalone applications. The decline of the PC is for the benefit of a lighter weight desktop on one hand and of course for the newer generation of smart phones and mobile terminals (Google's Android and of course Apple's iPhone and iPad). Chapter 10 is devoted to the Google desktop and will discuss these issues in more depth. [ 21 ]
Google and the Basics of Cloud Computing
What characterizes this type of IS, is the use of open standards, guaranteeing interoperability at all levels: • • •
Sharing identities and authorizations: Each application can work with identities that come from an external repository. Integration within enterprise portal solution: To unify application access. Integration with processes and data using indexation mechanisms and two-way exchanges that go beyond those offered by classical silos.
Windows
GUI Google Processing API
Google Search
Chrome and Chrome OS
GUI
Android
GUI
Marketplace
Google Processing API
Data
Data
Data
ERP
CRM
e-Commerce
Infrastructure
Postini Web Security
Finally, in Google's vision, the Google Apps suite is much more than a simple office suite: rather, it is meant to provide the basic building blocks for the IS of the future. For this reason, the platform offers many options to integrate the Google Apps services with other existing components. The Google Apps Marketplace, just like the Apple Store, provides easy access to solutions from partners that offer products and services that supplement the basic offer.
The economic impact of Cloud Computing A new economic approach to computing
The Cloud model deeply changes the economic model of computing. The previous evolution of computing had already favored immaterial investments in software rather than in hardware. Now, the economic model of the cloud goes one step further by suppressing the investment altogether for the consumer of computing power. [ 22 ]
Chapter 1
The manner in which operations are managed and the way the balance sheet is presented will be strongly impacted, starting with IT expenses. The on-demand principle will impact companies, namely by reducing the weight of their assets on the balance sheet and reducing the amount of capital frozen to that end. The pooling of services will provide an additional economy of scale.
Reducing costs and investments
From the customer's point of view, this economic model is rather close to outsourcing, but it simultaneously brings other benefits: •
Per-use pricing, which bases charges on activity (either stepwise or continuously)
•
Resource pooling logic that offers reduced costs
•
Functionality pooling logic that offers improved performance
In summary, the Cloud model provides increased economic flexibility by replacing a fixed investment with a cost that is proportional to the activity.
Reduced cash requirements
This benefit is magnified by the fact that the immediate availability reduces cash requirements. Inception phases, tests, and evaluation are most often done without acquisition, as Cloud providers offer their readily available environments. Eventually, the project life cycle is made shorter and simpler. Its financing becomes less onerous. Consumption of seed capital is reduced and, moreover, it is risk-resistant because the resources can be adjusted progressively when the need arises.
Improving cost visibility
Besides the benefits regarding the immobilization of capital and the savings on the costs of operation, the Cloud also helps improve the visibility of service costs. Observing the market, one notes that, in many cases, computing costs are measured per feature, per macro-activity (infrastructure, network, desktop, helpdesk…) or per platform (technical or functional). An increasing number of companies create a catalogue of services whose costs are measured and monitored.
[ 23 ]
Google and the Basics of Cloud Computing
The main benefit of the cloud is to propose a total cost for a service excluding internal costs. Contract management allows companies to precisely follow costs and to compare them with other solutions on the market. One corollary is the readability of the contract negotiated with the service provider involved; we can only hope that the present simplicity of this emerging economic model will not get lost in labyrinthine pricing policies.
Should the Cloud and Google be adopted now?
The questions that are often asked by IT departments, when discussing Cloud Computing, is: "What is the maturity of the concepts and of the solution?" "Should we go for it now?" "Wouldn't it be wiser to wait?" The answer was perhaps not obvious for Cloud pioneers in 2005-2007. Today however, there is no longer any doubt. Many studies show that the cost and new application benefits are so high that the companies that fail to adopt it will risk constant or even growing costs whereas their competitors will see them decrease significantly. The loss of business opportunities at a time when collaborative teamwork is becoming a necessity to guarantee employee productivity should also be taken into account. What is sure at present, is that smaller- to middle-sized organizations (5,000 to 10,000 users) will take advantage of the Cloud very quickly. Google's numerous references in this market demonstrate it quite clearly. The larger companies, whose ISs are much more complex, will first need to assess the impact of the Cloud on the governance and the organization (these points shall be dealt with in Chapter 3). But even for this market segment, the Google Apps have proved their effectiveness. Some references here are: Valéo, Malakoff-Médéric, Euromaster, particularly in industry and insurance. Finally, the move towards the cloud announced recently by Microsoft, a historic player in the desktop business, testifies the maturity of the concepts. Cloud Computing has with no doubt entered the phase of mass deployment.
Summary
This first chapter presented Google and the origins of the Google Apps solution. The key concepts of Cloud Computing were introduced together with their various incarnations: IaaS, PaaS, and the SaaS. Next, the compatibility of the various software architectures with Cloud Computing was discussed. The chapter concluded with general remarks regarding the impact of adopting the cloud in an enterprise IS. [ 24 ]
Why Trust Google? The SaaS model described in the previous chapter raises a number of security and data protection issues. At the same time, however, it offers new opportunities and new guarantees in those precise areas. This chapter presents Google's response to four important security-related issues: security against data theft, non-disclosure of data to third parties, guarantees as far as data availability is concerned, and finally, the existing solutions for retrieving data hosted by Google.
SaaS and data security
The distributed world that is emerging with the advent of SaaS raises new questions related to data protection and data security. However, existing solutions to those problems are often largely ignored and this contributes to anchoring doubt in the minds of many people. Too often, this doubt prevents the adoption of these new tools and ways of working. This is especially true in the business world, where such security issues are a particularly sensitive subject. Of course, it is perfectly legitimate for potential customers of Google to ask these kinds of questions. This chapter thus presents Google's response to these concerns, within the specific context of Google Apps, both on a technical and an organizational level. The present chapter specifically covers these topics: •
Protection against data theft. The list of potential ill intentions is a long one. They could for instance stem from hackers looking for money or just for fame, from rogue states, or from companies that practice electronic market intelligence.
•
Data confidentiality. This covers the existing guarantees against non-disclosure of data by Google employees who could access it.
Why Trust Google?
•
The availability of services and data. This covers, in particular, the conservation of data over time.
•
Reversibility. By this, we mean the possibility that should exist for each customer to quickly withdraw all data hosted in Google's datacenters.
Due to lack of space, we won't address in detail here each and every technical or legal aspect related to data security or data protection. But, when appropriate, we provide references to Google material for those readers who would like to go into more detail on these matters.
SaaS opportunities
The questions related to the aforementioned four security issues are obviously legitimate ones. However, they should not obscure the important fact that the SaaS model, on the contrary, in many respects contributes to improving the security of information exchanges. As itinerant lifestyles become more widespread, the occasions for losing data stored on thumb drives or portable disks obviously increase. The multiplication of computers on which this same data is used makes the problem even worse by increasing the likelihood that the files eventually get infected by a virus. Finally, the multiplication of downloads from one computer to another and the repeated use of mail attachments favors virus propagation. The situation just described should be contrasted with using a collaborative tool like Google Docs, for instance, where all documents are stored online, in Google's ultra-secure datacenters. No more worries about losing any documents! Moreover, each time a document is uploaded or downloaded from Google, it will undergo a set of extreme defense measures administered by Google mechanisms. Thus, no more worries anymore about virus spread either! Similarly, when a security hole is detected in an application, the SaaS model demonstrates significant advantages, especially when compared to the traditional procedure that involves installing software patches. Studies have shown that three to six months are often necessary before a patch is first made available by a software vendor and then actually deployed on all computers within a company. This extends the IS's period of vulnerability to attacks by the same duration. Conversely, fixing a security flaw in a SaaS services usually occurs much more quickly. Discovery, to begin with, occurs much sooner for simple statistical reasons: a much larger number of users are likely to detect it. The fix itself is faster too, because it happens directly on Google's infrastructure, without any user intervention.
[ 26 ]
Chapter 2
What's Google's take?
Google's vision about security is based on a strategy that includes 10 components that provide control of data storage, access, and transfer: •
Google corporate security policies
•
Organizational security
•
Asset classification and control
•
Personnel security
•
Physical and environmental security
•
Operational security
•
Access control
•
Systems development and maintenance
•
Disaster recovery
•
Regulatory compliance
We discuss the most important of these points in the next two sections. Let's conclude this introduction by noting that, for Google, establishing a genuine trust relationship with its customer, regarding security and confidentiality is of utmost importance. It is nothing less than the viability and the sustainability of its economic model which is at stake. The fact that stakes are so high for Google remains perhaps as one of its best guarantees of credibility and reliability on these matters.
The multi-layer security strategy Google corporate security policies
Google's security policies cover account data, corporate services, networks, change management, incident response, and data centers. All procedures are systematically challenged and updated. All persons employed by Google must comply with these policies. They are also given advice on security policies such as the safe use of the Internet and how to act when working from remote locations. Guidance is also provided on how to handle sensitive data. Special attention is given to emerging technologies such as the safe use of mobile devices and peer-to-peer software. All these documents are written with simplicity in mind, knowing that advice is only effective when the documents are actually read. �������������������������������������� More information can be found here : http://www.google.com/intl/en/corporate/
security.html [ 27 ]
Why Trust Google?
Organizational security
The Information Security Team is a full-time team comprised of world's best experts in information application and network security. The team is part of the Google Software Engineering and Operation organizations. It is in charge of maintaining Google's perimeter defense systems. They develop security processes and build security infrastructure. They play a key role in elaborating the company's security and standards. More specifically, members of this team are involved in the following activities: •
They conduct security design and perform code reviews
•
They monitor suspicious activity on Google's networks
•
They provide training to employees on complying with security rules, especially in secure programming
•
They help discover vulnerabilities and ensure that they are remediated quickly
•
They participate in various works in the security community outside of Google
Besides the Information Security Team, there are also Global Compliance teams in charge of ensuring statutory and regulatory compliance worldwide. Still another team is dedicated to physical security. Physical security of datacenters relies both on the strict confidentiality of their exact location and on the complex biometric tests that qualified personnel must undergo. Buildings are all unmarked to protect them from prying eyes. People who are not Google employees have only very limited access to datacenters. Intrusion tests are performed routinely to detect any possible failures in the procedures. All procedures implemented at Google comply with the most stringent requirements of an SAS 70 type II audit.
� ���������� This is a ����������� U.S. norm, �������������������� which is recognized ��� at ������������������������ an international level. ��� It ����������������������� defines the methods to �������� be used ��� by organizations in charge of internal controls and audits on companies. The SAS 70 of type II is normally issued after a sixth-month long period of study. It is more thorough than the type I.
[ 28 ]
Chapter 2
Asset classification and control
Security of customer data is of course essential and Google has extensive controls and processes to protect it. Google Apps run in a multi-tenant and distributed environment. Customer data is distributed across a large number of computers using clustered databases. Google uses a distributed file system (GFS) that was developed in house. The data is replicated on many systems for reliability. Files are given names that are generated randomly. They are thus not interpretable by humans. Requests from one service to another service are systematically authenticated and authorized. Administrative access to production applications by operations engineers is similarly controlled. Role and group management for engineers is performed in a centralized way. Access to production services or accounts is provided on an as-needed basis only. When a Google Apps user or an administrator erases a message or account, this data is deleted from all active servers and all replication servers. Pointers to the data are removed and the dereferenced data will eventually be overwritten by new data over time. When disks are being replaced, they are first erased, then this erasure is checked by two independent individuals. Each disk that was erased is tracked by its serial number.
Personnel security
The hiring process at Google takes security into account. Whenever possible, Google conducts criminal, credit, immigration, and security checks on people being hired. All employees are provided with security training. More in-depth security training is provided depending on the employee's role or position. There are confidential reporting mechanisms to ensure that employees may report any kind of security violation when they witness them.
Physical and environmental security
Mechanisms used to protect Google's data centers vary depending on their geographic location, because risks are obviously not the same everywhere. Security measures follow well-accepted best practices, among which: access cards designed by Google, cameras, alarm systems, and security guards. The data center buildings where systems are installed are physically separated from areas to which the public has access. Cameras monitor suspicious activity and facilities are systematically patrolled by security guards. Activity is monitored by HR cameras and is kept for later viewing, should it become necessary. [ 29 ]
Why Trust Google?
Access to data centers is restricted according to the role of visitors, not on their hierarchical position. As a consequence, even the most senior executives at Google are not granted access to the data centers. Data centers are designed for resiliency and redundancy to minimize single points of failure. Electrical systems are redundant, too.
Operational security
Google's strategy against malware relies on both manual and automated scanners that browse websites that could be a threat by propagating malware or organizing phishing. The blacklist of sites produced by this process has been integrated by most recent browsers. Multiple anti-virus engines are used to protect Gmail. This aspect of security will be discussed in detail in Chapter 5, Security Tools of this book. Internal traffic is analyzed for suspicious behavior that could be generated by botnet connections. Any kind of unusual behavior is traced by a proprietary correlation system. When a vulnerability requiring a fix has been discovered by the Security Team, it is logged, prioritized, and assigned to an individual who will be responsible for its resolution. The Google Security Team is available 24x7 to all employees, to help solve any security issue that may occur. Events that could impact customers are given highest priority.
Access control
Each employee is given a unique ID and account by the HR department upon hiring, with a predefined set of privileges. This unique account is used for all systems at Google. Systems require strong authentication wherever a password is needed. This mechanism uses one-time password generators. Each employee is granted a minimal set of privileges that can be augmented only by following a formal process that requires approval from the system owner, manager or other managers. These approvals are managed by dedicated workflow tools that record all changes that were made.
[ 30 ]
Chapter 2
Systems development and maintenance This is a policy that concerns the lifecycle of any software project. Design, development, and deployment of software benefits from two in-house consulting services: •
Security Design Reviews are design-level evaluation of a project's potential security issues
•
Implementation Security Reviews are implementation-level reviews meant to assess robustness against security threats
Security Consulting is an ongoing consultation on security risks for a given project. The development process satisfies the following requirements: •
Peer-reviewed design documentation
•
Adherence to coding style guidelines
•
Peer code reviews
•
Multi-layered security testing
•
Key requirements include robustness and maintainability
Disaster recovery
To minimize service interruption in the case of natural disaster or hardware failure, Google implements a disaster recovery program in all its data centers. This includes, in particular, the following measures: •
Data is systematically backed up and replicated across multiple systems and also to a secondary data center
•
The data centers are geographically distributed to maintain service continuity in the event of a disaster
In addition, Google has a business continuity plan for its headquarters in California. It assumes that people and services may be unavailable for up to 30 days.
Regulatory compliance
Regarding third-party requests for user information, Google follows the standard legal processes. If the request is considered valid by Google's Legal team reviews, the user or the organization whose information is required is notified unless prohibited by law.
[ 31 ]
Why Trust Google?
Google adheres to the US Safe Harbor Privacy Principles and has obtained a SAS 70 Type II certification.
Security at the user level
In September 2010, Google also introduced a strong authentication mechanism, which further increases end-user security by requiring users to enter a 6-digit code every time they log in. This 6-digit code is generated on the fly. This provides a solution to an old problem: the user/password protection is based only on the possession, by the user, of the knowledge of secret information, namely the password. Strong authentication requires moreover possession of a unique object, like a cell-phone with a specific number. We discuss this strong authentication mechanism in more detail in section 8.2.4.
Data privacy
Google adheres to the U.S. Safe Harbor principles on the protection of privacy.
The privacy principles that are implemented Google follows 5 principles which dictate its privacy policy:
1. Use private information only to improve user experience and to design new useful services. 2. Comply with all applicable laws regarding the protection of privacy. Develop tools that allow users to access and manage their personal information knowingly. The Google Dashboard is a simple web page that groups all the tools needed to manage personal data for each application and service. The details of the privacy rules that apply are summarized on the same page. 3. Notify a user explicitly when data is collected and explain what kind of use is made of that data. 4. Never take personal data hostage and allow users to adjust the level of privacy according to their needs. ���������������������������������������������������������������� For more information on privacy see the "Privacy Center" here: http://www.google.com/intl/
en/privacy.html ������������������������������������� The URL of the Google Dashboard is: https://www.google.com/dashboard
[ 32 ]
Chapter 2
5. Manage data in a responsible way by consulting the user and developer communities and by consulting external experts.
What data is collected?
A detailed description of the use that is made of personal data is provided in a document entitled Privacy Rules. When Google intends to use personal data for purposes other than those specified in this document, it will seek explicit permission from the user. The user may then choose to refuse such use. Let's look at the key elements of the Privacy Rules.
Use of personal information
Data such as the username, the password, mail address, or credit card number (in encrypted form, obviously) is collected for the sole purpose of improving the quality of service.
����������������� Available here: http://www.google.com/privacypolicy.html
[ 33 ]
Why Trust Google?
Cookies
Cookies are small files, stored locally on a desktop computer, which contain strings of characters, transmitted by a web server. They are used, for instance, to uniquely identify a user session. Google's goal, here as well, is to improve quality of service by storing for each user his or her preferences or search habits.
Connection data
Each time a user connects to one of Google's services, data such as the IP address, the type of browser, the language, and the time of day is collected for similar reasons as those previously mentioned.
Geographic location
Mobile terminals with a GPS can send geographic data to services like Google Maps. Note however that, if for one reason or another, a user does not want this geographic data to be sent to Google, he or she can simply disable it on the device itself.
Technical means
To ensure strict privacy, data is both encrypted and stored on servers in a noncontiguous manner. For even greater security, file names are randomized. For instance, it is totally impossible to reconstruct all files belonging to one user. To prevent hacking, the Google security team works in close collaboration with companies specializing in security to continuously optimize its infrastructures. Most of Google's software infrastructure is not standard but was developed specifically by Google for its own purposes. On the software side, each server is equipped with the strict minimum that is necessary to perform the tasks to which it is dedicated.
Availability of data and services
When facing a natural catastrophe or a failure of a local system, Google's basic principle to ensure constant availability of its services is always the same: redundancy. Data is systematically replicated in multiple data centers located in different areas. Moreover, robust failover software mechanisms ensure service continuity, whatever happens. Another important architecture principle at Google, which helps ensure optimal availability, is a thorough decoupling of software from hardware. For example, no process depends on the availability of a particular piece of hardware for its execution. [ 34 ]
Chapter 2
To inform its customer in a transparent way, Google provides a web site, called the Apps Status Dashboard, as shown in the previous screenshot, which lists, grouped by date, each malfunction that occurred on any of the Google Apps. It also indicates the actions undertaken by Google teams to fix them and it gives an estimate for the time necessary to restore the situation to normal.
How difficult is it to leave Google?
It is almost second nature, for some actors in the computer industry, to try and create populations of captive customers by making migration to a competitor's solution as difficult as possible. Most often they do so by all technical, financial, and legal means imaginable. Google, on the contrary, is betting on retaining its customer in the long run. It therefore tries to earn their trust by letting each of them leave Google solutions for solutions of its competitors when they wish. This is reflected in the rather unusual approach of the Data Liberation Front, a group of Google engineers whose goal since 2007 has been to make the move to other non-Google solutions as easy, cheap and smooth as possible, especially regarding data migration!
����������������� Available here: http://www.google.com/appsstatus#hl=en � Data Liberation Front website: http://www.dataliberation.org/home
[ 35 ]
Why Trust Google?
Not surprisingly, the Data Liberation Front encourages users to be alert before choosing any SaaS solution and to ask themselves the following three questions: •
Will I be able to retrieve my data easily if I wish to abandon this service?
•
How much will the retrieval operation cost me?
•
How much time will I have to spend on this?
As far as Google services are concerned, and more specifically for the Google Apps that we shall discuss extensively in this book, the Data Liberation Front proposes practical information for the best way to retrieve data (or to enter them).
On the Data Liberation Front site: the menu on the left allows selection of a Google service; the central part provides explanation of how to retrieve data from the application. The "revolutionary iconography" suggests the unusual or even subversive aspect of the approach.
The mission that the Data Liberation Front has set for itself is an ongoing process. According to the team, the process is currently about two thirds complete.
[ 36 ]
Chapter 2
Is it legal to use Google Apps?
It is obviously perfectly legal to use Google Apps, both for public and private organization whether in the U.S. or in Europe. Google respects the strict EU regulations on data protection and adheres to the principles of the U.S. Safe Harbor regarding privacy protection.
Summary
This chapter discussed four issues related to securing data in the cloud and the answers provided by Google. The main points were security of data against theft, privacy of customer data within Google, and data availability in case of a disaster. We also discussed the means provided by Google for a user to retrieve data from any Google application. This last point is of utmost importance and was the subject of special attention from Google's Data Liberation Front, whose aim is to make leaving Google services as easy as possible.
[ 37 ]
Part 2 The Google Apps Platform Communication Tools Collaboration Tools Security Tools Extending the Platform
The Google Apps Platform The Google Apps Platform includes a large array of applications and services that are tightly integrated with one another and that can be put into three categories. The communication tools category comprises Gmail, an email system that is currently the state of the art in its category. In the same category, Google Calendar is an online agenda with advanced sharing and publication features. Finally, Google Talk is an instant messaging system combined with audio and video communication. The Google Groups tool allows, among other things, managing mailing lists and can also be put in this first category. Chapter 3, Communication Tools will be dedicated to these tools and will also touch on the availability of these tools on mobile terminals. The collaboration tools make up the second category of services. Google Sites and Google Docs are the most important among them. Google Sites is a tool for quickly creating simple websites and publishing them. In some aspects, Google Sites is closer to a wiki than a traditional web content management system. Google Docs is an online office suite that includes, as you would expect, a word processor (Google Documents), a spreadsheet (Google Spreadsheet), and a presentation tool (Google Presentation). Google Video also belongs to this category of sharing tools. These topics will be addressed in Chapter 4, Collaboration Tools. All these use the same address book, and this contributes largely to the integration of the various tools. This very high level of integration is what distinguishes the Google Apps from competing offers. For this reason, we will emphasize using these tools jointly when one application benefits from the services of another. For example, you can easily include a Google document or an agenda in a website created with Google Sites.
Finally, the last category of tools comprises the security tools. These are the Postini services. Postini is a specialized company that designed these services, and was subsequently acquired by Google. Here, we'll distinguish protection tools such as antivirus and anti-spam tools from the archiving and search tools. These tools are intended for domain administrators. Chapter 5, Security Tools introduces the primary features that are available in the Postini administration console which, as we shall see, is rather complex! Each deployment of the Google Apps is associated with a domain name (my_googleapps.com). A console linked to this domain name groups all administrative tasks related to a deployment. These are described succinctly at the end of Chapter 3, Communication Tools and Chapter 4, Collaboration Tools for the application themselves and in Chapter 5, Security Tools for the security services. The following figure schematically represents the interconnection between the Google Apps and the IS. It also shows the tasks implied by a migration to the Google Apps starting from a classical architecture. The migration issues will be the subject of Part 3. Target Architecture
Initial Architecture
Synchronizing accounts
Company directory Mail server
User desktop with mail client Managing accounts
Google accounts
http
SMTP, POP
or
Archives
Company directory
Quarantine
Authentication [SAML 2.0]
or User desktop with browser
http
Managing Google accounts, Google Apps and Postini services
Transition between a classical email system and a Google Apps deployment.
http
Google Apps services are available in three editions: •
The Standard Edition is for personal use. It is free.
•
The Google Apps for Business Premier Edition is for companies and costs $50 per user per year.
•
The Google Apps for Education version is primarily for universities.
The features of the various editions are summarized in the following table: Google Apps (free)
Google Apps for Education
Google Apps for Business Edition
Free
Free for accredited institutions
$50 per user per year
Communication tools: YES Gmail et Google Calendar
YES
YES
Collaboration tools: Google Docs et Google Sites
YES
YES
YES
Other enterprise applications: Google NO Video and Google Groups
YES
YES
Maximal number of users
50
No limit
No limit
Maximal number of emails sent
500 emails per day per account
2000 emails per day per account
2000 emails per day per account
Storage space
7.6 GB
25 GB for mail
7.6 GB
Price
Availability
No SLA
99.9 % SLA
99.9 % SLA
SSL security, SSO and strengthened security requirements
NO
YES
YES
Advertisements
YES
None
None
Support
NO
24/7 phone support
24/7 phone support
Online help
YES
YES
YES
Thus, Google Apps is a suite of collaborative tools aimed at both large and small companies. Beyond the online tools that come with the Google Apps, Google offers Google Apps Engine, a platform for deploying and hosting web applications and Google Apps Marketplace, a platform for purchasing services. These two topics will be addressed in Chapter 6, Extending the Platform. Name of the Application
Description of the Application Communication Tools
Gmail
Email by Google. It includes search tools and offers offline access. It also integrates instant messaging and video.
Google Calendar
Calendar and planning tools.
Google Talk
Instant messaging. It also exists as a standalone application and integrates with Gmail. Collaboration Tools
Google Docs
An online office suite, which includes a word processor, a spreadsheet, and a presentation tool.
Google Sites
A collaborative web content management tool that borrows from the wiki philosophy.
Google Video
A video sharing tool.
Postini Services
A set of security (anti-spam, anti-virus, various filters) and mail archiving services
Security Tools
Extensions of the Platform Google Apps Market Place
A website for purchasing applications to enhance the Google Apps platform.
Google Apps Engine
A solution for designing and hosting web applications on Google's high-availability infrastructure.
Communication Tools This chapter presents the two applications that are at the heart of the Google Apps suite: namely Gmail and Google Calendar. We do not provide a tutorial for these two applications but rather we give a critical description of these tools and compare them with the more traditional desktop applications. The emphasis is on the high level of integration of these tools, which is precisely one of the main strengths of the Google Apps solution.
A brief history of Gmail
Gmail was designed in the early 2000s under the leadership of Paul Buchheit, the developer who also designed AdSense, Google's contextual ads mechanism. Gmail was made publicly available on April 1st, 2004 in a limited number of countries including Germany, Austria and the UK. This announcement occurred on a date that is traditionally well suited for making hoaxes and this first raised some skepticism among technological players. Jonathan Rosenberg, the vice president of Google products himself, had to clarify the situation and attest that Gmail was actually not a joke but indeed a fully functional product! During a preliminary phase, Google used an invitation mechanism that allowed only a few lucky owners of a Gmail account to invite a limited number of other people. This allowed Google to control the growth of the new system. During the first year, the demand was so high that accounts were at times traded above $150 on eBay. As soon as the number of invitations was raised, the price automatically dropped and Google soon decided to change its policy and banned the sale of Gmail accounts. Gmail was then made publicly available without invitation, starting Feb. 7th, 2007 but remained officially in beta until July 7th, 2009.
������������������� At the same time, ������� Google �������������������������������� announced that it was launching ����������������������������� an extreme offshore strategy ��� by ������������� building the Google Copernicus Center on the moon to house its employees!
Communication Tools
Since June 5th, 2008, the Gmail Labs service allows users to test new, experimental features for Gmail on a volunteer basis. This allows Google engineers to gather feedback from the most motivated users and continuously improve the service. For example, the Google Gears plug-in that enables offline access to Gmail, was first proposed within the Google Labs. It has now been available since January 28th, 2009. The size of storage space went up from 1 GB in 2007 to 7.4 GB in early 2010 for the Standard Edition and up from 7 GB to 25 GB in the Business Edition.
Gmail in detail How is Gmail different from traditional messaging tools? Nothing to set up on the client machine
Gmail is an online messaging tool. From a user perspective, it requires strictly no setup whatsoever on the client machine. Everything just happens in the browser which should, however, be a recent version. In any case, the browser should be kept up-to-date to take advantage of the latest improvements in JavaScript parsing and in HTML 5 implementation. Version 6 of Internet Explorer and even Google's own Chrome 3.0 are not supported any longer, because they might not render Gmail properly in the near future.
Constant improvements
The Gmail service is steadily improving, partly thanks to feedback from users who test its newest experimental features through Gmail Labs. We stress the opt-in character of this approach: these functions must be explicitly activated by the user, as by default they are not.
Gmail Labs features may be turned on one by one.
[ 46 ]
Chapter 3
The GUI (Graphical User Interface) performance of Gmail relies mainly on two things. First, Gmail's GUI was designed in the, now classical, sober style that is Google's trademark. Second, Ajax technology provides for optimal responsiveness of the GUI that can legitimately be compared to an installed application (so-called heavy client). Moreover, you can be quite confident that Google's engineers will design tools that take advantage of the new HTML 5 standard by the time it is eventually finalized (2011). Let us note that Google is actually a major contributor to this emerging standard.
No more mail servers!
As all data is being hosted in Google's datacenters, mail servers are no longer needed, thus saving users the cost of maintaining the associated hardware and software infrastructure. More importantly, the complex and delicate tasks of maintaining a constant quality of service, by appropriately scaling the infrastructure proportionally to the user load, are now completely Google's responsibility. Without a doubt, Google can be recognized as one of the most competent companies in terms of proving the scalability of its services. Account management and security service monitoring are both performed through an administrative web console. These questions will be addressed shortly in the paragraph devoted to administration and more broadly in Chapter 7.
State-of-the-art security tools
Since its inception, Gmail has had particularly effective anti-spam tools. Currently, the features related to email security (anti-spam, anti-virus, anti-phishing), archiving (indexing messages, search, privacy policy), and web security (filtering, anti-virus, anti-spyware) are all supplied by the Postini services. Postini is actually a leader in this market and it deals with billions of emails daily. Managing Postini services however, is a rather complex task. It definitely requires that Google Apps domain administrators be properly trained in order to configure these services optimally. More detail on this topic will be given in Chapter 5.
���������������������������������� Ajax is a technical solution for �������� dynamic ������������������������������������������������������� page loading that combines several open standards like ������ HTML, ����� DOM, or JavaScript. In particular, Ajax avoids reloading an entire page when only parts of it need to be refreshed. ����������������������������������������������������������������������� More information pertaining to the HTML 5 standard is available here: http://www.whatwg.org/specs/ web-apps/current-work/
[ 47 ]
Communication Tools
A high level of reliability
Just like any other service provider, Google commits to an SLA . The key figure is 99.9% availability for all Google Apps services. In January 2011, Google announced an even stronger SLA, removing the provision for maintenance windows, as well as a measured Gmail availability during 2010 of 99,984%. See: http://
googleenterprise.blogspot.com/2011/01/destination-dial-tone-gettinggoogle.html.
In the event that this level is not reached, Google will offer free days of service as compensation, proportionate to the outage time. Service levels Actual Level of Service
Number of Free Days in Compensation
@mycompany.test-google-a.com
Once the MX record has been modified, the final address, linked to the domain name will be used. It has the following form: <username>@mycompany.com
When a pilot project is set up, there are still other solutions, which we shall describe in Chapter 13, The Pilot Project.
Activation of Postini services
A wizard assists the user in the activation process. The automatic registration process starts once the terms of the contracts have been accepted by the administrator. The process can last up to one hour. The progress can be monitored directly in the Google Apps console.
The activation process of the Postini services in the Google Apps administration console. The status of the registration process can be checked.
The rest of the activation procedure for Postini services comes down to rerouting the incoming mail to the Postini services rather than directly to Gmail. Again, this is done by changing the MX-records. A wizard is available here as well. A delay of 24-48 hours may be necessary to ensure that the MX record changes propagate throughout the DNS tree. Once the Postini services have been activated, it's a good idea to check that mail indeed flows through them, and then to delete the now obsolete MX records. A few more settings for Gmail need to be adjusted, in particular to ensure that no messages coming from Postini services will be considered as spam by the Google Apps filters. Details are provided by the activation wizard. Recall that a detailed description of the features of Postini was given in Chapter 5, Security Tools. [ 131 ]
Managing a Google Apps Domain
Creating users and groups
There are several strategies for creating Google Apps user accounts.
Manual creation
This is the easiest and most straightforward way to create a new account using the administration console (as shown in the following screenshot):
Creating a user directly in the Google Apps console
Creating new users comes down to entering their last names, first names, usernames, and passwords. Later on, this new user can be added to one or more groups (see the section below devoted to group creation).
Defining other destinations
An administrator can define a specific routing for each user.
[ 132 ]
Chapter 7
Uploading a CSV file
A simple way to simultaneously define a list of users is to upload a CSV file from the console. This file should have the structure shown in the following table: A
B
C
D
username
first name
last name
password
Emc2
Albert
Einstein
Dgf7çgfh
iPad
Steve
Jobs
Vlc9fv8é
Requiem
Wolfgang Amadeus
Mozart
Pgoa77r0
The structure of the CSV file for a list of users
Before loading the file, the system will ask the administrator to choose between creating new users or modifying existing ones. The system will send a notification mail once the process is complete. Beyond 500 users, it is better to split the list into smaller pieces. There are many small companies that offer services to support these and related tasks. The Google Apps Marketplace (see Chapter 6, Extending the Platform) is a good place to look for this kind of service, especially under "Small Business Implementation".
Creating a group
Groups are generally created to define mailing lists. Sending a message to each member of the group is done by sending a message using the address of the group instead. A group can also be used to share documents with Google Docs, agendas from Google Calendar, a site from Google Sites, video, or to manage access to these resources. The only information required to define a group is a name and an email address. The other attributes are a short description of the group and permissions. The latter determine which categories of users can send messages to this group (and not the other way around); we'll come back to this shortly.
[ 133 ]
Managing a Google Apps Domain
An administrator can create a group directly from the console and add members to it, which can be either users or other groups (as shown in the following screenshot):
Adding a member to a group in the Google Apps console. The status of the new member of the group should be chosen: owner or member.
A new member can be added as an owner of the group or just as a regular member. This status will later determine the rights of this member regarding this group.
There are three kinds of access levels and one custom mode
There are three kinds of access levels and one custom mode: •
The team level. Any user from the domain my-domain.com can send messages to the group and see who is a member.
•
The announcement level. Only group owners can send messages to the group and see who is in the group.
•
The restricted level. Only group members can send messages to the group and see who is in the group.
•
The custom level. The administrator defines which categories of users can send messages to the group and see who is in the group.
In the custom mode, the authorizations can be defined in detail
[ 134 ]
Chapter 7
Advanced methods
For specific purposes, there are other migration tools. Now we'll look at three of them. More details can be found in the section devoted to account creation on the Google Apps help site.
The provisioning API
This API is only available for the Premier and Education versions. It is intended for developers who have to design custom migration tools. Using these APIs, the Google accounts can be automatically updated from an existing directory. A vast array of provisioning solutions from Google's partners is available on the Google Apps Marketplace.
The Google Apps Directory Sync tool
This is a free tool, which allows provisioning user accounts from an LDAP directory such as Microsoft Active Directory or Lotus Domino. The tool actually synchronizes the data in the Google Apps accounts, shared contacts, and groups with information in an LDAP directory. The administrator has to define rules for this. More precisely, Google Apps Directory Sync ensures a one-way synchronization from the directory to the Google Apps accounts; the LDAP directory is left as is.
The Google Apps Provisioning Toolkit
This is a free web tool, which allows quick creation and update of Google Apps user accounts (20 users per second, on average). The information source for the definition of the user accounts can be a CSV file, an LDAP directory, or a relational database. Furthermore, the tool offers the possibility for users to create their Google accounts themselves by simply asking them to log in using an existing mechanism.
Activation of user-managed groups
Administrators of a Google Apps domain can decide to let the users create and manage their own groups:
Activation in the console of user-managed groups. A detailed description of the project is available here: http://code.google.com/p/google-
apps-provisioning-toolkit/ [ 135 ]
Managing a Google Apps Domain
This authorization can be granted at the level of a Google Apps domain only and not to specific individuals. It can be revoked at any time. The advantages of such flexibility are numerous for end users. They will be able, for instance, to create their mailing lists or groups, which will be authorized to view private content. Groups that are reachable from outside the Google Apps domain can be created as well. This last option will prove particularly useful when setting up customer service or a help desk.
Adjusting domain settings
The domain settings group all information that is not specific to any particular user or to any particular service. General Settings: This section gathers settings such as the name of the organization and the choice of a locale. It also contains the activation of advanced features of the console and of an SSL connection for all domain users. Settings related to the account: This contains a link to buy more accounts and information for contacting the administrator. Names of the domain: This allows adding aliases to the domain name. This is useful, for instance, to allow users to use more than one address to receive their mail.
Managing advanced elements
While not exhaustive, here are a few settings from the "advanced tools" section in the Google Apps console, which are worthwhile to knowing. Details can be found in the online help. Managing authentication: Activation of SSO (Single Sign On) is the most significant setting here. SSO is a mechanism based on the SAML standard that makes it possible for a user to authenticate only once to access many applications in the IS. Chapter 8, Federated Identity and SSO will be entirely dedicated to this subject. The administrator can also require a password with a minimal length and monitor the security level of passwords for each user. It is also possible to activate OpenID, which will allow users to choose Google Apps as their authentication provider when accessing third-party applications that implement this standard.
SAML: Security Assertion Markup Language
[ 136 ]
Chapter 7
Google Analytics enabling. Recall that Google Analytics is a free service offered by Google that generates statistics about the visits of a website and thus provides a measure of its marketing efficiency. The administration APIs. This section in the advanced settings provides links to three especially useful APIs: •
An account management API that will help design automatic sychronization tools with existing directories.
•
An API that provides access to statistics on Google Apps usage. It will be useful to feed reporting tools.
•
An API useful when migrating from an existing messaging system.
We shall come back to these APIs in more detail in Chapter 9, Advanced Integration.
Application settings
Each Google App has its own settings in the console (as shown in the following screenshot):
Settings for specific applications
Now we will look at the primary ones.
Gmail
The activation of advanced features of Gmail such as Labs, video, or chat is up to the administrator of the Google Apps domain. Among the other useful settings, let's mention the possibility of creating a "white list" of IP addresses that will never be considered as a source of spam. The Postini Services should in particular be included in this list. [ 137 ]
Managing a Google Apps Domain
Another feature that will prove very useful when setting up a pilot for a migration project (see Chapter 13, The Pilot Project) is the automatic routing of messages whose destination is unknown to a mail server other than Gmail. It is also possible to disable the POP and IMAP access.
Google Docs
An administrator can choose to enable or disable Google Docs and decide which rights to grant to which members in the domain. Here are the available options. The more restrictive ones are listed first: •
Users cannot share any document outside the Google Apps domain to which they belong. An option however allows them to receive documents from outside the domain.
•
Users can share a document outside the domain but will receive a warning.
•
Users can share a document outside the domain and will receive no warning.
•
The users can publish public documents on the Internet with no limitations.
The administrator can moreover control whether users will be able to submit their own templates and change the available categories for sorting them (see Chapter 4, Collaboration Tools). The administrator can choose which categories of templates to make available for domain users and can create new ones.
Google Talk
Besides enabling the service, the console also allows enabling or disabling chat history. Notifications to users who send instant messages outside the domain can be enabled.
Google Calendar
An administrator can define three levels for sharing calendars with other users in the domain: •
Allow sharing only availability information
•
Allow sharing all information but in read-only mode
•
Allow sharing all information in read-write mode
[ 138 ]
Chapter 7
In a similar way, an administrator can define the default sharing options for calendars within the domain. In contrast with the visibility of agendas outside the domains (which only the administrator can change), users will be able to change this level of visibility: •
No sharing whatsoever between users in the domain
•
Share only availability information
•
Share all information
Postini services
Security services and archiving services can only be enabled and disabled.
Google Video
Besides enabling and disabling the service, the administrator can define a list of recommended tags to use to describe a video. He or she can define a list of users authorized to upload videos.
Google Sites
The settings are here very similar to those of Google Docs. They allow the administrator to restrict the level of sharing of a Google Site with users outside the Google Apps domain. The ability for users to define their own templates can be removed. The URL of the site can be redefined and aliases can be defined.
Synchronization with smartphones
The Google Sync service allows the synchronization of contacts and agendas on a smartphone with those in Google Apps. The service is based on Microsoft Exchange (used by iPhones and Windows Mobile phones, for instance). It can be disabled.
[ 139 ]
Managing a Google Apps Domain
Additional services
It is possible to add services to those that are already available in the Google Apps console. The US version (see domain settings for this) usually offers the most options.
The additional services that can be added in the Google Apps console
Recall here that the two services Google Apps Marketplace and Google Apps Engine were described in a dedicated section in Chapter 6, Extending the Platform.
Summary
This chapter covered the primary administration tasks in a Google Apps domain. Each step, from the registration of a Google Apps account to the activation of Gmail and the Postini services, has been described. The most important tasks to master for an administrator are account and group creation and granting appropriate rights to various user categories. Only a few concepts need to be understood, like the "owner" or "member" of a group. Knowing how to manage groups within Google Apps is important to create mailing lists and for granting specific rights (read, update for Google Calendar, Google Sites, Google Docs) to certain categories of users.
[ 140 ]
Federated Identity and SSO The aim of SSO techniques is to avoid the need for users to authenticate each time they use a new application. The first section reviews the main issues related to this question. The federation of identity among several security realms is the main topic here. The second section presents the basic concepts of the SAML standard that will be necessary to understand federation of identity and authentication delegation when introducing Google Apps into an enterprise IS. The next section is about using a local ID repository for authenticating users within a Google Apps domain. Finally, the last two sections address two other connected topics: integration of Google Apps in an existing SSO and using Google Apps as an ID provider.
The SSO issues
There are numerous issues related to requiring users to authenticate several times, usually once for each new application. First, there is the obvious discomfort of a tedious repetition of authentication procedures that, moreover, often vary from one application to the other. This discomfort can even lead to a decrease in productivity. A more serious concern, at least in an enterprise context, is the multiplication of passwords that are required. Most users are not able to remember this plethora of passwords, a problem that is compounded when they are asked to change them often. What usually happens then is that they gather all passwords in one place easily accessible to themselves and… to others! The absolute zero of security is reached when a post-it with a list of passwords is stuck on the screen…
SAML: Security Assertion Markup Language
Federated Identity and SSO
SSO (Single Sign On) techniques attempt to solve these issues. All such techniques contain two inseparable elements. First, there is a central ID repository (a database, an LDAP directory, a file, and so on) that people use to authenticate, usually once a day, when they first access the information system. Second, the SSO mechanisms relate this central security context with the many security contexts specific to the various applications, whether these are web applications such as the Google Apps or classical standalone applications running on the user's desktop. Establishing this link between security contexts is a delicate and complex matter. On the one hand, trust relations must be established among the entities that provide the authentication (IdP: ID Provider) and those which consume it (SP: Service Provider). On the other, the parameters, security contexts, and authorizations should be transmitted from one context to the other in a seamless way for end users. Summarizing, here is a list of issues that any SSO solution should address: •
Allow the use of several passwords for different applications
•
Allow automatic scaling when the number of applications in the SSO domain grows
•
Ensure the privacy of parameter exchanges among the various security contexts associated with the different SPs
•
Define a federated identity by relating several local identities
•
Make sure that no correlations can be established between the activities of any given user in two different security contexts belonging to the same federated identity
•
Never propagate security information in an uncontrolled way from one security context to another
•
When sharing parameters between security domains occurs, users should be given the possibility to express their consent or their refusal
•
Impose no specific authentication technology
•
Ensure interoperability between technologies
•
Allow the use of certificates to establish trust relationships among IdPs and SPs
•
Allow each SP to control access to its own resources
This is where the SAML 2.0 standard comes in: its aim is to bring lasting solutions to all issues related to establishing a federated identity. Currently, the reference opensource implementation is Shibboleth.
[ 142 ]
Chapter 8
The SAML standard The SAML concepts
SAML 2.0 is a norm for federated identity, defined by the OASIS consortium. The functional context where SAML comes in, involves at least two entities (humans or systems) which exchange authentication and authorization data. The first one is named the "asserting party"; this is the entity that makes a claim about something being true. The second one is named the "relying party"; this is the entity that uses the assertion being made. The entity about which an assertion is being made is named the subject (or the principal). To help anchor these ideas, keep in mind the following basic situation: the "relying party" is a service whose access is protected and which uses the information delivered by an authentication mechanism, the "asserting party", to grant access to a user. The user who wishes to access the service and whose identity is being checked is the "subject". It is not hard to see that, for this responsibility scheme to work properly, it is necessary to establish a trust relation between both roles. More precisely, the "relying party" should have no doubt that it is dealing with the "true" asserting party and not with an impostor. We'll see shortly how this trust relationship can be ensured within the Shibboleth implementation (see the following section, devoted to this tool). In the most general setting, the SAML norm defines use cases where several roles collaborate to accomplish a task that implies exchanging authentication and authorization information. But the only use case we shall be interested in in this book, is the Multiple-Domain web Single Sign-on (MDSSO or simply SSO). Before going further, however, let's define a few terms that belong to the SAML vocabulary: •
Authentication delegation. This refers to using an external system (to the application or to the organization) for authenticating a user.
•
Federation of identity. This refers to establishing two-way associations among various ID definitions that are specific to some applications, some organizations or, more generally, to some security contexts. It implies delegating authentication to just one of the security contexts. The ID and the associated parameters should then be propagated securely between the contexts with the agreement of the user.
OASIS: Organization for the Advancement of Structured Information Standards
[ 143 ]
Federated Identity and SSO
The following figure illustrates the concept of federated identity in the context of a trip reservation on the portal of an airline company. The portal accesses the IS of a car rental company and the IS of a hotel reservation agency. The three applications each take, in turn, the roles of the IdP and the SP during the reservation process. It is expected that each security context generally uses different "user/password" pairs. It is up to the user to enter these credentials when he or she first uses one of the services. The keys, or nicknames, are generated automatically and make federated identity a reality. Subsequently, John Smith will only authenticate with the airline company. John Smith Flight booked with john smith
company.com
Wants to book a hotel with johns after federation acceptance by company.com
Wants to book a car with jsmith after federation acceptance by company.com
cars.com
Agreement on the nickname Kjh765vb to designate John Smith.The local identities are mutually hidden.
hotels.be No correlation!
Agreement on the nickname nbv234nz to designate John Smith.The local identities are mutually hidden.
An illustration of a federated identity among three security contexts: that of an airline company, that of a car rental agency, and that of a hotel reservation center. The federation is achieved using keys known only to those contexts that use them. No correlation between the activities of John Smith on the different websites can be demonstrated.
•
A SAML assertion. This is the basic building block of SAML. It is a claim about a subject, which an asserting party claims to be true. The detailed structure and the legitimate content of such an assertion are defined in a formal way using an XML schema, namely the SAML assertion XML schema. In principle, these assertions are created by an asserting party on request from a relying party.
•
A SAML protocol. This is a set of requests and assertions that are involved in identity management. Again, the set of allowable protocols is defined in an XML schema, namely the SAML protocol XML schema.
[ 144 ]
Chapter 8
• •
A SAML binding. This specifies how protocol messages are sent over lowlevel communication layers such as HTTP or SOAP.
Lastly, a SAML profile, as we already saw, refers to a use case that has been formalized within the SAML norm. The following figure summarizes the relation between these concepts: Profiles Combinations of assertions,protocols and bindings intended to make a use case
Bindings Associations between SAML protocols and low-level communication protocols
Protocols
Requests and responses involved in identity management
Assertions
Claims about the identity of a “Principal”
Four nested SAML concepts: assertions, protocols, bindings, and profiles
Let's now address MDSSO. The two relevant entities are the IdP, the identity provider and the SP, the service provider that were already mentioned above. We distinguish the following two variants, the second of which is actually the one used by Google Apps.
Use case: IdP-initiated Web SSO
To describe this use case, let's consider, once more, the example of an online trip reservation. A user visits the portal of an airline company, airline.company. com, where he or she logs in. Here, the company plays the IdP role. Assume that during the reservation process the user is redirected, within the portal, to a car rental company, cars.company.com, the latter playing the SP role in this case. In this context, it is up to the IdP, airline.company.com, to initiate the redirection, which explains the name for this use case. Two sub-cases should be distinguished: •
If the user has already made a car reservation with the car rental company in the past, through the same airline portal, then identity federation already occurred and the user won't be asked to authenticate again.
[ 145 ]
Federated Identity and SSO
•
If however, this is a first visit to the car rental agency through the portal of the airline company, the user will be required to enter his or her credentials for cars.company.com. The SSO system will then establish the appropriate binding with the ID defined on airline.company.com.
In both cases, the SP cars.company.com trusts the IdP airline.company.com to correctly check the identity of the customer. The SAML 2.0 norm also defines an optional Discovery Service (DS) that allows a user to look for an IdP. We'll come back to this point shortly, when we cover Shibboleth.
Use case: SP-initiated Web SSO
A simple example of this use case is when an employee wants to access Gmail, which is protected by a local authentication mechanism. Gmail thus takes the SP role and the local ID directory, that of the IdP. Here, the SP role initiates the external authentication request, hence the name of the use case. The following section, devoted to authentication delegation, will describe in detail how such an authentication mechanism can be set up. Note that the SSO wording is slightly misleading here, since delegation of authentication does not necessarily imply setting up a SSO in the strictest sense of the term. It is however entirely possible to integrate Google Apps in an enterprise SSO. To avoid any possible confusion, let us emphasize that, once the identity of a user has been checked within a Google Apps domain, he or she will have access to any of the Google Apps services. This set of services should be considered, from the point of view of SSO, as just a single web application and not as a set of applications that benefit from identity federation.
An implementation example: Shibboleth
Shibboleth is an open-source reference implementation of federated identity principles as they are defined in the SAML 2.0 norm. The software is developed under the auspices of the Internet2 consortium and is distributed under the Apache 2.0 license. Shibboleth implements the three primary elements from the SAML 2.0 norm, namely the following:
Internet2 is a non-profit consortium whose mission is to develop technologies that will enable reaching very high speeds on the Internet.
[ 146 ]
Chapter 8
•
The Service Provider (SP). This is the software layer that protects the access to an existing service. It is in charge of sending authentication requests to the IdP and consumes the SAML assertion it sends back. On a LAMP platform, the SP includes a Linux daemon and an Apache module. On a WIMP platform, it includes a Windows service and an ISAPI filter.
•
The Identify Provider (IdP). This is the software layer that handles the authentication requests by delegating them to an existing system. It produces answers that will be used by the SPs. These answers contain all the data defining the ID of the user as well as associated parameters and authorizations. The Shibboleth implementation is a web app that can run in the Tomcat container, for instance.
•
The Discovery Service (DS). This allows the user to choose an IdP from a list. The Shibboleth implementation comes with a web application that provides this feature.
Shibboleth 1.3 does not itself provide an authentication mechanism. Thus, an external authentication mechanism will be needed. One possibility is to use the authentication services of the Java container in which the IdP runs; Tomcat is just one such example. The following figure succinctly describes a web-SSO authentication process (actually, it is really a delegation of authentication) which involves the three entities implemented by Shibboleth, namely the SP, the IdP, and the DS: •
The user tries to access a protected resource. If the user recently accessed another resource that is protected by the same Shibboleth SP, he or she will be able to access it immediately, without further ado. If, however, this is a first attempt or if this is the first time that he or she is using this particular SP, then the user's browser will be redirected to the Discovery Service.
•
The Discovery Service presents a list of IdPs, usually institutions or organizations where the user is already referenced and that are likely to check his or her identity. The user chooses one of these IdPs and will then be redirected to the corresponding login page. This step can be bypassed when the browser remembers a previous choice from the same user. This step is not mandatory in the web SSO profile but SAML 2.0 makes it possible.
•
The user is shown the login page he or she is familiar with and enters his or her credentials, which are then transmitted to the SP.
LAMP is an acronym that designates a set of open source software: Lunix for the operating system, Apache for the web server, MySQL for the database and PHP, Perl or Python for the scripting language. WIMP is an acronym that refers to the computing paradigm defined by: Windows, Icons, Menus, and Pointing device. ISAPI is an acronym for "Internet Server Application Programming Interface". It is an API from Microsft's IIS web server.
[ 147 ]
Federated Identity and SSO
•
The SP checks that the user who was just authenticated has the appropriate rights to access the requested resource. If that is the case, access is granted. The SP can also use the parameters that were transmitted, together with the authentication data, to define an authorization level, for instance.
The IdP sends the SP a certificate that proves that the it (the IdP) really is who it claims to be. The SP can thus trust the SAML assertions made by the IdP. In the case of Google, it is the ACS (Assertion Consumer Service) that performs the check of the certificate (see the following section devoted to authentication delegation). Discovery Service(DS)
2
1
Service Provider(SP)
3
Identity Provider(IdP)
4 Confidence relationship
The authentication process with Shibboleth: 1. A user attempts to access a protected resource. The user's browser is redirected to the Discovery Service (DS). 2. The DS asks the user to choose an IdP where he or she is referenced. 3. The IdP generates a login window. 4. If the user was granted the appropriate rights, he or she accesses the requested resource. The IdP sends a certificate to the SP in order for the latter to check the legitimacy of the SAML assertions made by the former.
Even if the principles used by Shibboleth remain quite simple and intuitive, the actual setup of the tool requires real technical expertise.
Delegation of authentication for Google Apps Workflow with Google Apps
The workflow of an access to Google Apps with authentication delegation corresponds to the web SSO profile in the SAML norm we discussed earlier. It involves eight steps, as shown in the following figure: [ 148 ]
Chapter 8
•
A user wants to access Google Apps.
•
Google generates a SAML authentication request. Things happen seamlessly for the user. The request contains the name of the application the user wants to access.
•
The browser redirects the request to the IdP service.
•
The IdP decodes the authentication request and extracts the parameters encapsulated in the SAML request. The IdP authenticates the user either by asking him or her to enter his credentials or by validating session cookies.
•
The IdP generates a SAML assertion that contains the account ID for that user. The request is signed with the private key of the IdP.
•
The IdP sends the signed SAML response to the Google's ACS (Assertion Consumer Service) by means of a browser redirection.
•
The ACS checks the genuineness of the response using the certificate (public key) from the IdP.
•
Lastly, the user's browser is redirected to the Google Apps service whose name was stored in the URL for the duration of the process. User
Service Provider
Id Provider
1
2 3
Browser
3 4 5 6 6 7
ACS URL
8 The authentication steps for accessing a Google Apps domain when authentication delegation is used
[ 149 ]
Federated Identity and SSO
Settings in the administration console
Enabling and adjusting settings of the authentication delegation is performed using the Advanced tools in the Google Apps console.
Configuring authentication delegation in the Google Apps console
The first URL should point towards the SSO redirection page of Shibboleth (see below). It has the following form: https://my-domain.com/idp/profile/SAML2/Redirect/SSO
For the time being, Shibboleth does not yet implement any logout procedure. The second URL should point towards a static page that asks the user to quit his browser. The third URL should point to a page that allows users to change their password. At the bottom of the page, a button allows the administrator to upload the certificate generated by Shibboleth to Google, which can use it in the ACS to check the authenticity of the responses.
[ 150 ]
Chapter 8
Shibboleth configuration
The details of Shibboleth configuration are too complex to be discussed here. The most important task involves setting up various XML configuration files and metadata files for the IdP. Without going into detail, here is the list of files to be created or updated.
Describing the SP and the SAML binding
The aim here is to configure Shibboleth so that the IdP "knows" that it is talking to a Google Apps domain using the HTTP protocol. The file is google-metadata.xml.
Specifying the SAML profile
This is where the SAML profile that will be used is defined. This defines the workflow of the authentication process. The file name is relying-party.xml.
Specifying which attributes to transmit
Google expects to find the username in the SAML assertion returned by the IdP. It is necessary to properly configure Shibboleth for that. This is done in two XML files: namely, attribute-resolver.xml and attribute-filter.xml. When deploying to a production environment, it is likely that the Google Apps username won't be the same as the ID used with the IdP. In this case, the Google username should be stored in an LDAP directory or a database.
Strong authentication with Google Apps
Google also provides a strong authentication mechanism that strengthens the security of data access. Recall that strong authentication implies supplying at least two proofs of identity. The usual password is obviously the first one. The other proof is a physically unique object that the user exhibits as a "proof of possession", just like a passport. For Google Apps, this second proof of identity is a single-usage code that the user receives on his phone. This way, even a pirate who has stolen a password won't be able to access the account without owning the associated phone.
[ 151 ]
Federated Identity and SSO
The disposable code provided by Google is fetched using a mobile app named Google Authenticator. Once the app has been installed on the smartphone, it is necessary to associate it with the user's account. Two methods are available. The first method is to scan a bar code that displays on the smartphone. The second is to enter, in the phone, a secret code that was generated on the user's Google account.
Google Authenticator applications on mobile
Entering the disposable code in the Google interface
The generation of the single-use code by the Google Authenticator uses open standards from the Initiative for Open Authentication (OATH). The application runs on most smartphones: Google Android, RIM BlackBerry, and Apple iPhone iOS. Strong authentication is only available in the "Premier", "Education", and "Government" editions of Google Apps. This feature should be activated by the Google Apps administrator. This strong authentication mechanism can be used by a single user on several Google accounts. This is usually termed multi-account access. [ 152 ]
Chapter 8
Integrating Google Apps with an Enterprise SSO
For integrating Google Apps with an existing SSO, a simple delegation of authentication is not enough. If nothing is done, the Shibboleth IdP will require that the user authenticates locally each time he or she accesses the Google Apps domain, even if he or she already did so earlier. This, obviously, is not the desired SSO behavior. In true SSO, the user should be required to authenticate only once, typically when first accessing the IS daily and later, the authentication should be automatically taken care of. One of the most commonly used SSO mechanisms in companies is the Kerberos technology that comes with Windows. We shall briefly present the principles on which Kerberos relies and then explain how to configure Shibboleth so that the IdP uses Kerberos for authentication.
The Kerberos protocol
Kerberos is a communication protocol that allows computers in non-secured networks to mutually prove their identity to one another. The technology is based on symmetric cryptography and needs a trusted third party. For a Kerberos deployment, this trusted third party is the so-called Key Distribution Center (KDC), itself composed of two logically distinct entities: the Authentication Server (AS) and the Ticket Granting Server (TGS). The KDC handles a database of secret keys, each of them being known only to the KDC and to the entity to which it is associated. Possession of one of these keys is used to prove the identity of its owner. The basic mechanism behind Kerberos is an exchange of tokens to prove the identity of stakeholders. The security of the mechanisms relies, partly, on the short period of validity of the tokens. Here is how a Kerberos authentication works: •
A user authenticates with the AS, which sends back a timestamped token T1.
•
The user sends this token T1, provided by the AS, to the TGS. The TGS authenticates it and sends back a request to access a service.
•
If the user was granted appropriate rights for accessing the requested service, he or she will be given another token T2 from the TGS.
•
The users presents the token T2 to the service as a proof that he or she is entitled to access it. [ 153 ]
Federated Identity and SSO
Accessing the AS is usually performed using a password with a long period of validity. The token (T1 above) returned by the AS after this basic authentication can be reused several times to get other tokens (T2 above) from the TGS to access other applications. A full description of setting up a SSO with Kerberos is beyond the scope of this book. We will assume here that such a setup has already been done and shall only describe the main tasks involved in configuring Shibboleth to use Kerberos rather than a traditional login password page.
Setting up Shibboleth for Kerberos
Configuring an IdP with Shibboleth is a complex and technical topic. A dozen XML configuration files are involved. What interests us here is the login.config file, which describes the authentication mechanism to use. The actual authentication process is taken care of by the Java platform on which Shibboleth is running. This security mechanism, among others, is normalized under the name Java Authentication and Authorization Service (JAAS). It is thus essential to master the JAAS configuration of a Java platform, a topic for which numerous tutorials are available. Here are the basic steps to follow to configure Shibboleth to use Kerberos: •
In the first step, we must configure Shibboleth to define a so-called Login Handler (a Shibboleth concept) that tells Shibboleth to use the JAAS mechanism from the Java platform.
•
In the second step, we must specify, on the Java platform itself, meaning in the JRE configuration, which JAAS Login Module should be used. It is here that we specify that the Kerberos Login Module should be used, rather than, say, the LDAP Login Module.
•
More details are given in the online configuration guide of Shibboleth and in the JAAS guide of the Java platform.
JRE = Java Runtime Environnement. The Java execution platform.
[ 154 ]
Chapter 8
Google Apps as an ID provider with OpenID Introduction to OpenID
In the previous sections, a Google Apps domain played the Service Provider role. It is thus dependent on an external authentication process taken care of by an IdP. Conversely, it is also possible to let a Google Apps domain play the role of an ID provider. This is the topic of this last section. The protocol used is, in this case, OpenID. OpenID is an authentication protocol, not a standard like SAML. It does not rely on any central directory to work. This is in contrast with Shibboleth's implementation of SAML, which federates identities using a central enterprise directory. OpenID is based on trust relations among service providers and identity providers. A SP need only decide which OpenID IdPs it will trust. The SP will then be able to give its customers the choice to use one of these IdPs for authentication. Besides Google, there are numerous other OpenID providers. The most famous ones are probably: MyOpenID, Verisign, Yahoo, and Orange. One point worth emphasizing is that, with OpenID, it is the user who chooses which IdP will be used.
This decentralized nature of OpenID makes it a technology of choice for noncommercial purposes. However, it is much less likely for a company to use OpenID to protect the access to its IS. By definition, there will be no central list of users. There is no security issue, however, associated with allowing employees to use their professional Google account as an IdP for private purposes.
[ 155 ]
Federated Identity and SSO
No information belonging to a Google Apps domain will ever be disclosed outside the Google Apps domain in the OpenID token provided by Google. One point to keep in mind, though, is that the domain name of the Google Apps domain that is used to perform the authentication will be, implicitly revealed when OpenID is enabled. That may be a reason not to enable OpenID on a Google Apps domain.
The login window of the mindmeister.com site. Entering the name of the domain can, implicitly, reveal a user's relationship to an institution. The administrator should be aware of this fact before activating OpenID in the console.
We show below how to activate OpenID in the Google console and how the authentication process works when a third-party application uses the ID provided by Google.
OpenID and Google Apps
The previous figure shows the steps involved when a user uses a Google Apps account to authenticate with a third-party application. The steps are: •
An application requires a user to authenticate and proposes a list of OpenID providers, one of which is Google.
•
The user chooses to authenticate using his or her Google Apps account.
•
The application sends a request to find the XRDS document, which contains the address of the service provider.
•
Google sends back the XRDS document.
•
The web application sends an authentication request using the provided address. [ 156 ]
Chapter 8
• •
•
•
This redirects the user to the Google Apps login page. The user authenticates as usual, using the Google Apps account. Google Apps displays a confirmation page. The user may have to accept that some parameters will be used or cancel the authentication. If the user confirms the request, he or she will be redirected to the web application. This application can only use the data that users accept to transmit. The application can then use the authorizations, if any, that were transmitted by Google. User
1
Third Party Web Application
2
Browser 3
4
Google Authentication
5
6
8
7
9
The steps of an authentication process that uses OpenID with a Google Apps domain
The OpenID feature can be enabled in the Advanced tools menu in the Google Apps console:
Enabling OpenID identity provider in the Google Apps console
To this day, OpenID is still not widespread, but this could change with the increase in high-profile IdPs, Google being one of the most important ones. [ 157 ]
Federated Identity and SSO
Summary
This chapter discussed two standards related to authentication delegation and setting up SSO, namely SSO, and OpenID. When using the Google Apps, their roles are actually opposite. SAML, whose reference open source implementation is Shibboleth, allows delegation of the authentication for accessing a Google Apps domain to an existing IdP, typically an enterprise directory. Conversely, OpenId allows a Google Apps domain to play the role of an ID provider when accessing third-party applications, provided these implement the OpenID technology.
[ 158 ]
Advanced Integration This chapter reviews a few typical ways to integrate Google Apps in an enterprise IS. After discussing, in the last chapter, how to integrate Google Apps in an existing security context, we will describe here four different modes of integration, complementary to each other: the Google Apps APIs make up the first solution. They allow enterprise applications to access the Google Apps. Next, the Secure Data Connector, on the contrary, can open access to enterprise data for Google Apps users, even when the data lies behind an enterprise firewall. We shall also recall how the Google Apps Engine service can run custom code on the Google Apps platform to build scalable applications. Finally, we cover widgets, which are small applications that can help integrate Google Apps services into external web pages.
Integration modes
To put things in perspective, recall that integrating the Google Apps in an identity federation network is probably the most important step towards a full integration. This was the topic of the last chapter and can be thought of as a prerequisite for more advanced integration.
Advanced Integration
The following figure shows the four modes of Google Apps integration that we shall discuss:
3
Portletinan enterprise portel
1
Entreprise applications
API Gmail
4
Enterprise firewall
TunnelServes
API Calendar
Secure Data Connector
2 API Contacts
LDAP Service Web Documents
Google App Engine
The four modes of integration for the Google Apps: Mode 1 corresponds to using API to give applications access to the Google Apps, mode 2 corresponds to using the Secure Data Connector, mode 3 corresponds to integration in an enterprise portal using "portlets", mode 4 corresponds to Google Apps Engine.
Accessing Google Apps from a third-party application: APIs
The first integration mode is the classical one, relying on APIs supplied by Google. This allows very tight integration with the existing IS, because it occurs at the level of applications code. This way, data managed by Google Apps, as well as their key features, become available to code written by developers. Most of these APIs implement three common mechanisms: •
User authentication
•
The possibility to make requests
•
The possibility to handle conflicts between different versions of the applications [ 160 ]
Chapter 9
There is a common protocol used by several of the Google Apps, such as Google Calendar or Spreadsheet, which is called Google Data Protocol. It draws on the REST architecture. Let us briefly recall here the basic REST principles. REST is actually more an architecture style than a genuine protocol. REST attempts to capitalize on existing protocols and technologies such as HTTP and XML to provide a simple way of exchanging information, at least when compared with SOAP, for instance, which requires complex marshalling and un-marshalling operations. When using REST, the basic data manipulation operations known as CRUD operations, are simply associated to the PUT, GET, POST, and DELETE that are defined in the HTTP protocol. Furthermore, a resource is identified by its URL. The two main advantages of REST are its simplicity and the omnipresence of the principles on which it relies. Any programming language that allows you to create HTTP requests and parse XML code will do for using Google Apps APIs. To make the life of developers easier, Google also provides a set of client libraries in the primary languages (Java, PHP, Python, .NET, Objective-C), which will facilitate creating HTTP requests by using an appropriate set of abstractions. We shall distinguish two categories of APIs below.
APIs for application management
Here is a summary of the features available in the first category of these APIs.
Calendar Data API
This API allows you to create new events and update or delete existing ones. This is actually the same API used by the developers of a Calendar itself. A client application might therefore access any kind of calendar, whether private or public or associated with a group. It allows you to read or publish information from all calendars.
Contacts Data API
Here is an API that will be useful for designing applications that manage user accounts. Applications that synchronize Gmail contacts with those in as Smartphone, with a social network, or with a messaging system are examples of applications of this API.
REST: Representational State Transfer CRUD stands for: Create Read, Update, and Delete, which make up the minimal set of operations necessary to manipulate any kind of data.
[ 161 ]
Advanced Integration
Documents List Data API
This API is used for managing a list of Google Documents. A client application using it can search the content in such a list, update its content, or delete it.
Sites Data API
This API is used for accessing the content of a Google Site, for publishing content, or changing it. It is thus possible to design collaborative applications that manage Google Site content. The API also allows you to upload or download documents, to read the history of changes to the site, and even to monitor visits to the site.
Spreadsheets Data API
Just as for the Calendar API, this one is the same as that used by the Spreadsheet developers themselves. It can be used, for instance, to store data from a spreadsheet or for building new custom graphical representations of spreadsheet data.
APIs for domain management
APIs in this category are intended mainly for teams that are in charge of Google Apps domain administration (see Chapters 12 to 14) or that want to perform a migration to Gmail from an older messaging system.
Domain Shared Contacts API
This API can create, update, or delete contacts belonging to the contact list shared by all users. It is also possible to perform searches using a list of criteria.
Email Migration API
This API can help migrate mail data from any source to Gmail. The source can be nearly anything: a mail server, an interface compliant with a messaging protocol, or even the database of a mail client. Each uploaded message can have its label defined as well as its status or its creation date. Tools for both the end user and the administrator are available in this API.
Email Settings API
In complement to the previous API, this one provides access to the Gmail settings for each user. It is thus possible to define preferences for mail transfer, for POP or IMAP, or aliases for mail addresses.
[ 162 ]
Chapter 9
Provisioning API
Also, in complement to the migration API, this one allows you to manage user accounts. Accounts and groups can thus be created programmatically. By synchronizing local data with that of a Google Apps domain, this API can help alleviate mail delivery disruptions during the migration process.
Reporting API
This API allows you to monitor the usage of applications in a Google Apps domain. Various kinds of reports can be generated in CSV format.
User Profiles API
This API provides access to the profile of each user including the items defined by the domain administrator. Profiles can be read as well as updated.
The Secure Data Connector
The Secure Data Connector (SDC) is a mechanism whose aim is to allow Google Apps services to access enterprise data that lies behind a firewall, in a controlled way. "Controlled" here means that only users duly authorized to access this data will be able to benefit from the SDC. The SDC is an application that runs on a server in the company IS. There are three Google Apps services that can take advantage of the SDC. We will briefly indicate for each of them how an invocation of the SDC is performed: •
Google Spreadsheet (see Chapter 4) can use the SDC through the
import function
•
Google Sites gadgets (see Chapter 4) should use the makeRequest API to access the SDC
•
Web applications running on the Google App Engine (see Chapter 6) must use the urlFetch API to access the SDC
The workflow of a SDC call
The five steps of a call to the SDC services are shown in the following figure. The following list describes the role of each system: 1. One of the three Google Apps services mentioned previously sends a request to the tunnel servers that are in charge of encrypting the data. [ 163 ]
Advanced Integration
2. One of the tunnel servers checks that the user has been granted the right to access the requested resource. Filters can be set up at this stage to limit access to the IS through the SDC, depending on which Google Apps service or application is making the request. The tunnel servers are permanently connected to the SDC using an encrypted channel. The SDC is a process that runs on a server within the company's IS. Usually, this server lies behind a firewall and this is the reason why an encrypted tunnel is necessary. 3. The tunnel protocol allows the SDC to be permanently connected to the tunnel servers, to authenticate the incoming data and, in turn, to encode the data returning from the enterprise IS. 4. The SDC uses resource rules to validate that a user has the appropriate rights to request a particular resource. 5. The SDC sends a request to the service, which answers. The SDC then encodes this response and sends it back through the encrypted tunnel to the Google Apps that made the request in the first place. Gadgets Google Sites Google Spreadsheet
Google App Engine
Google Apps domain
1 2 3
Tunnel Servers
IS Enterprise firewall
4
Secure Data Connector
LocalConfiguration.xml XML
Documents
5
XML
ResourceRules.xml
LDAP
Web Service
The Secure Data Connector makes enterprise data, lying behind an enterprise firewall, accessible to Google Apps
To summarize, the SDC has three roles: it decodes the encrypted data from the tunnel servers that encoded the data from the Google Apps, it routes the requests to the appropriate service, and eventually, sends back the resource in encoded form. [ 164 ]
Chapter 9
Setting up an SDC Activation in the console
The SDC must be enabled in the Google Apps console as shown in the following screenshot. The username for accessing the SDC is the following fixed string secure-data-connector-user. The password, on the other hand, has to be specified by the administrator. This username and the password should both be entered in the localCondiguration.xml file of the SDC.
Activation of the SDC and entering the password in the console
Local configuration of the SDC Configuration of the SDC uses two XML files.
The first, named localConfiguration.xml, contains all parameters that are needed to establish communication with the Google Apps from a specific domain. The most important parameters are the following: •
The domain name where the SDC will be installed
•
The username (a fixed string, see above) and the password such as defined in the Google Apps console
An agent ID, agentId, which will be referred to in the configuration file that specifies the access rules. [ 165 ]
Advanced Integration
The second one, named resourceRules.xml, defines which users are authorized to access local resources. More precisely, this file lists rules. A number is associated to each rule which specifies its priority level. Among the important parameters for each rule, you'll find: •
A reference to the agent through the agentId parameter in the localConfiguration.xml that we mentioned above
•
A URL that localizes the resource we want to make accessible within the IS
•
Another URL that should be used in the Google Apps domain to access the resource identified by the first URL
•
A number that specifies the priority of the rule
•
A list of the email addresses of the users allowed accessing the resource
Running custom code on Google App Engine
Google App Engine (GAE) is Google's offering in terms of a robust PaaS infrastructure. GAE enables the deployment of web applications, which scale when traffic increases or when more storage space is needed.
Several programming languages can be used, in particular Java and Python. The distributed nature of the GAE implies using a non-relational storage space, named the Datastore. Designing business rules should thus be adapted accordingly. Global vision of Google App Engine for java
Google sites
Google Apps
Enterprise data SDC
Google App Engine Application
Admin Console
Memcache
Mail
Cron
Image manipulation
URI Fetch
Users
JDO/ JPA Data Store
The architecture of a Java application deployed on Google App Engine. The SDC allows an application deployed on GAE to access enterprise data located behind a firewall. PaaS: Platform as a Service. Designates a material and software infrastructure whose aim is to facilitate deployment of enterprise applications, while reducing the cost related to these infrastructures.
[ 166 ]
Chapter 9
Recall that the GAE is one of the three Google Apps services that can take advantage of the Secure Data Connector to access enterprise data. For more detail on GAE, refer to Chapter 6, Extending the Platform.
Inserting Google Apps gadgets in a portal
A gadget is nothing but a mini web app that runs within a simple web page or a portal. The following figure shows two such examples, available in Netvibes, a public portal:
Two gadgets that run in the Netvibes portal, one for Gmail and one for Google Calendar
Designing gadgets is rather easy. Only HTML, XML, and JavaScript are needed. The HTML code and the JavaScript code (Flash code is another option) are encapsulated in an XML file. It contains three distinct parts: •
The content () is the actual HTML and JavaScript code that contains the whole logic of the gadget
•
The user preferences (<UserPrefs>) define controls that can be used on the gadget
•
The gadget preferences (<ModulePrefs>) that defines such things as the width of the display, its title, or its author
Google proposes a variety of tag libraries and JavaScript code that speeds the development of gadgets for various environments. The following table lists a few examples: [ 167 ]
Advanced Integration
Name of the API or Library
Description
Execution Context
Gmail Gadgets
Allows the design of gadgets that act on the Does not matter content of mail. They can offer advanced preview features for some audio or video content.
Calendar Gadgets
Allows the design of sophisticated gadgets that use Google Calendar's data and events.
Does not matter
Sites Gadgets
This API allows an aggregation of several external data sources for publication in Google Sites. It allows circumvention of some security restrictions that apply to dynamic web content.
Google Sites
Wave Gadgets
Allows you to design robots and gadgets integrated in Google Wave. Their main purpose is to automate some conversion or translation tasks.
Google Wave
Spreadsheets API
This is for designing gadgets that improve Google Docs or other applications, which use spreadsheet features. It enables designing alternative graphical representations of the content of a spreadsheet or combine the content with other sources.
Google Spreadsheet
A few APIs available for designing gadgets that use Google Apps data
Google storage
Google storage is a "REST type" service (see the beginning of this chapter for a short introduction) that can store large files (up to 100 Gb with a monthly bandwidth of 300 Go) on Google's replicated infrastructure. This is comparable to Amazon's S3 service. The information is structured as "objects", which have a "data" component and a "meta-data" component. Objects are immutable once they are created. An object can be suppressed or replaced with another more recent version, but incremental changes are not possible. Objects are put in so-called "buckets" that can be nested.
[ 168 ]
Chapter 9
The main available operations are: •
Upload and download from anywhere
•
Sharing files in a controlled way with users and groups
•
Updating metadata
•
Creating or deleting buckets
•
Fetching lists of objects or of buckets
•
Deleting objects
For the time being, the service is available in beta version to a limited number of developers.
Summary
Four means of advanced integration for the Google Apps have been presented: the APIs, which allow external applications to access data handled by the Google Apps; the Secure Data Connector that, conversely, allows Google Apps services to access enterprise data behind a firewall; the Google App Engine that can host web apps on Google's software and hardware infrastructure and, finally, the Google gadgets that are mini web apps that can be embedded in other web pages.
[ 169 ]
Google "Workstation" While the previous chapters outlined the impacts of Google's SaaS on the infrastructure of your Information System, this chapter additionally drills down into Google's offer regarding the user desktop and experience, using Chrome (Google's browser) as a cornerstone of a Google "Workstation". Next, we'll summarize the main features of the two operating systems that Google has published: Android, currently shipped on dozens of mobile device models and Chrome OS, a revolutionary operating system that brings a small-footprint and speed to the table to meet the specific demands of a new way of working online.
Accessing your Information System
Today's two most common means of access to an Information System are the user desktop and mobile devices (that is, smartphones, iPads, and so on), the latter gaining ever more popularity. At first glance, their evolution with respect to online access may seem contradictory: on the one hand, the browser has become a "one size fits all" application vis-à-vis other desktop applications; on the other hand, a handful of micro and highly specialized applications make the best use of a few high-performance web services. Google's offering regarding the user desktop and experience has been playing out within that dual and somehow conflicting motion.
Google “Workstation”
The user desktop
Until recently, the traditional user desktop hosted collaborative tools as well as enterprise applications running proprietary, client-server protocols. While "webizing" enterprise applications dates back to over 10 years ago, "webizing" office productivity applications is much more recent. Applications like Google Documents, Google Spreadsheet, and Google Presentation from the Google Docs suite, detailed in Chapter 4, are examples of online productivity tools. For the moment, the features of such applications remain rather rudimentary and online collaborative applications do not provide either the user-friendliness or the feature completeness that their desktop counterparts do. Yet this evolution to online applications seems unavoidable as it fits into the SaaS trend embraced today by the major web players. The imminent arrival of HTML 5 and the acute competition among the major players, who all seek to provide an end-user experience for online applications as close as possible to that of desktop applications, could reinforce this tendency. Do not kid yourself here: these changes are signs of the impending decline of the "all Windows" era on the user desktop!
Mobile devices
Let's take a look at accessing the IS via mobile devices, such as Apple's iPhone or iPad, or smartphones running Android or Windows Mobile. All such mobile devices currently provide specific applications for email access, calendaring, and contact lists. The combination of thin applications (with user interfaces specifically tailored for mobile devices) and peformant web services is currently the approach that offers the best end-user experience. Of particular interest in Google Apps are the web applications that were specifically designed for Apple's iPad. For enterprise use, the most relevant applications are Gmail and Google Sync.
[ 172 ]
Chapter 10
Gmail web app, adapted for the iPad
Google Sync on the other hand synchronizes Gmail, Calendar, and Contacts to the iPad native applications.
[ 173 ]
Google “Workstation”
Google's offering
Google's offering for the user desktop has been thought out with this complex context in mind and is comprised of: The following schema symbolically positions the Google products within a software and hardware stack.
Internet Cloud
Client Side Applications
Gmail Calendar Sites Spreadsheet
Google Chrome
Google Talk
Operating System
Google Android
Hardware
Nexus One
Chrome OS
Google Gpad
Google products laid out in different software and hardware layers: Google Apps in the Cloud; Google Chrome as the (essentially) lone application running on Google Chrome Operating System; mobile devices using Android as their operating system, as this point.
Chrome OS and the user desktop
Assessing that most of today's activity on a computer is carried out online, Google seeks to extend this model to its logical end by two primary means: In the Cloud, with Google Apps, a continuously improved SaaS offering, detailed in Part 2 of the book. On the user desktop, with just what is needed (and nothing more) to take advantage of these services in an optimal way. This minimalist approach, driven by performance and sobriety (which have been Google's signature from the beginning) has given rise to two products: Chrome, a next-generation web browser both performant and elegant, and Chrome OS, a lightweight and minimalist operating system capable of quickly launching the browser. That's it! Done. [ 174 ]
Chapter 10
To remove any possible doubt, let's emphasize that all Google Apps (fully addressed in Part 2 of the book) smoothly operate on all browsers: IE, Firefox, Opera, or Safari!
The Chrome web browser
Google Chrome is the web browser developed by Google. Released to the public in December 2008, its core is built on of 25 code libraries developed either by Google itself, sometimes over the course of many years, or by free software foundations, like Mozilla.
The graphical interface
Once more, sobriety is the differentiating factor in Chrome graphical interface. Tabs are laid out above the navigation buttons unlike other browsers where they are set underneath. The tabs can be dragged off the main window or, symmetrically, dropped onto an existing one. Pop-ups are bound to the tab they originated from and are only visible when the tab is active.
The graphical interface of Google Chrome web browser whose standard navigation buttons, tabs (laid out above other elements), and "omnibox" data entry area are its key elements
Another breakthrough in Chrome's user interface is its unified data-entry area named "omnibox." It allows typing in URLs as well as search keywords. In any case, typing triggers auto-completion based on previously visited sites and Google Suggest. When opening a new tab or window, Chrome displays thumbnails of the eight most visited sites. [ 175 ]
Google “Workstation”
In line with the SaaS philosophy, Chrome allows the creation of shortcuts to launch web applications (Gmail, Google Calendar …) whose windows' navigation elements are then deactivated, so that they blend into the user desktop, thus making web and desktop applications look alike.
A shortcut to launch a web application with a Chrome window free of any classical menus and controls
In provision for the upcoming (or eventual) adoption of the HTML 5 standard by the W3C, Chrome is already HTML 5 enabled, primarily in terms of built-in audio and video standards. The Flash Player used for video on many sites will be directly built into Chrome version 5.
Security and reliability
Chrome is designed using a multi-process architecture. Each tab runs its own process, independently of others. One tab can crash without crashing Chrome itself. Likewise, any malicious process that might execute within a tab would not have access to sensitive data handled by the other tabs. Actually, every process runs in a sandbox where it is literally deprived of its rights, in particular writing to the local file system. However, some plugins like Adobe Flash Player, overrun the sand box principle. For security reasons, they are run as separate processes dedicated to one tab and one plugin. An incognito ("no trace") mode is also available in Chrome, keeping it from storing history or cookies from the sites the user visits.
Performance
Complex and dynamic Web 2.0 pages require high performance when executing JavaScript code. Gmail is one such application, demanding high-speed processing on the client side. Google's developers thus devoted special care to have designing Chrome's JavaScript engine, which was the object of dedicated project at Google. Chrome relies on DNS pre-loading to speed up navigation between sites. The expected date for the final adoption of HTML 5 by W3C varies, depending on sources and level of optimism, from the end of 2010 to 2022 and beyond… The V8 JavaScript Engine.
[ 176 ]
Chapter 10
Miscellaneous features
Chrome includes Gears, which enables offline features for web applications; the topic was addressed in Part 2 of the book. Since the beginning of 2010, a gallery of extensions to Chrome lists more than 1500 applications, ranging from the utilitarian (a built-in dictionary…) to the silly (adding a "Don't care" button in Facebook!). By the end of 2010, Chrome Web Store will allow any individual to look for web applications as currently offered to companies through Google Apps Marketplace. Free or paid applications will be classified, assessed, and ranked by end users. Every web application available on the Chrome Web Store will be developed using standard web technologies and will consequently be runnable in any recent web browser. "Installing" on Chrome will offer the advantage of creating a handy shortcut that appears in much the same manner as the most visited pages do.
Shortcuts to launching web applications in a Google Chrome tab
Last but not least, Chrome has an automatic update feature. No user action is required. If the update takes place while the browser is running, Chrome will use the updated version when the browser is restarted. Most of Chrome's source code, including the JavaScript engine code, is available as an open source project: Chromium.
[ 177 ]
Google “Workstation”
The Chrome OS operating system
Chrome OS should be released in 2011, for free. It embraces the SaaS philosophy we have been stressing, offering a minimal software infrastructure that enables running a single application: Chrome. Today, most users of Information Systems agree upon a handful of key expectations. Keeping these expectations in mind, the key concepts in the design of Chrome OS have been: sobriety, speed, and security. Chrome OS is based on the free operating system, Linux. Hardware targets for Chrome OS are netbooks or tablets. Chrome OS features will include advantages of the SaaS model: •
Web browsers, with Google Chrome and Chromium.
•
Operating systems, with Chrome OS and Android Mobile.
•
Booting the system should be almost instantaneous to be able to quickly check email.
•
Users should not be required to manage the logistics of copies and backups of their documents.
•
Reconfiguring the system each time new pieces of hardware are added should not be necessary.
•
Users should not have to deal with updates.
•
Performance of the system should not degrade over prolonged uptime.
•
Boot time is expected to be less than 10 seconds. Full support is provided for latest web standards including Adobe Flash.
•
Because all Chrome OS settings are stored in the cloud, the user experience will be the same on any computer.
•
Security features include special protection against malware. Each process runs separately in a restricted environment called the sandbox. A self check, called verified boot, is performed by the OS to make sure it was not corrupted.
•
Updates happen transparently without any user action. This way, the latest versions of all the software are used.
•
A Chrome Web Store offers hundreds of applications that are reviewed by other customers.
[ 178 ]
Chapter 10
The source code will be freely available within the Chromium OS open-source project. One of the main expected benefits of this openness is the operating system security. As the code will be scrutinized by the user community, security breaches will be quickly detected and corrected.
The graphical interface
The user interface will be very similar to Chrome, with different types of tabs. Web pages and applications should all display in the same set of tabs. As far as off-line access, Chrome OS will naturally take advantage of the HTML 5 standards. One concern for an operating system like Chrome OS, fully dedicated to online applications, is printing. With the project Google Cloud Print, Google's ambition is to provide a dramatically simplified user experience: printing a document from any application, from any machine, to any printer. Google Cloud Print is to be the interface between applications (online as well as desktop) and printers selected by the user, without any drivers installed locally.
Performance
Boot time has been reduced to a minimum of a few seconds. Unnecessary tasks, such as initialization of floppy disks, have simply been removed from the boot sequence. The Linux kernel has been modified to account for performance enhancements, too. Further promoting performance and thinness, Google has requested that its hardware suppliers use SSD instead of regular hard drives.
Android and mobile devices
Android is an operating system for mobile devices. It is comparable to Apple's iPhone OS and Microsoft's Windows Mobile. At the end of 2009, some 20 mobile phone models were already using the Android operating system. Android is built on a simplified release of the Linux kernel, as is Chrome OS. The Java code of applications running on Android has to be compiled for a modified JVM, the Dalvik Virtual Machine. The entire source code of Android is available under the Apache license, which allows any vendor to add proprietary extensions without having to give them back to the open-source community. � ���� SSD �� = ������ Solid ��������������������� State Drive or flash ����� drive
[ 179 ]
Google “Workstation”
Main features Storage
Handled by a database: SQLite
Connectivity
GSM/EDGE, UTMS, WiFi, WiMAX.
Messaging
SMS, MMS.
Audio and video
H.263, H.264, MPEG-4 SP, AMR, AMR-WB, AAC, HE-AAC, MP3, MIDI, OGG Vorbis, WAV, JPEG, PNG, GIF, BMP.
Catalog of applications
Android Market : 40,000 applications, free or paid.
Multi-touch
Native.
Bluetooth
Native since release 2.0. Android main features
Competitive advantages
Android's primary advantage compared to its direct competitors, iPhone OS and Windows Mobile, is its tight and advanced integration with Google Apps (see Part 2). Android comes free of the hassle of configuration and setup: just a user name and password to access your Google Apps account and off you go!
Gmail user interface on Android: all features found in the regular Gmail (labels, starred items, and so on) can be found on Android
[ 180 ]
Chapter 10
Considering the variety of mobile devices Android is likely to be installed on, it will be up to mobile vendors to port and upgrade Android to their own hardware. They will be free to upgrade or not when a new release is made available by Google. The business model of a vendor is based more on selling new peripherals than upgrading its existing installed base. Android upgrade policies thus differ from those of its direct competitor iPhone, whose vendor Apple supplies both the OS and the hardware.
Summary
With Software as a Service as the new IT paradigm, accessing the Information System from a user desktop or a mobile device has raised new security, performance, and user-interface requirements. This chapter has addressed the strategy Google has adopted to meet these new challenges. This strategy mainly relies on a joint effort pursued on the web browser front, with Chrome, a speedy browser, and on the operating system front, with Chrome OS, a speedy OS dedicated to quick and efficient operation of its lone application: Chrome.
[ 181 ]
Third-Party Extensions This chapter is a logical continuation to Chapter 6, which presented various solutions to extend the Google Apps solution. When performing advanced integration of Google Apps into the IS, third-party applications or extensions are often the best choice. This chapter presents a selection of three products we think are particularly representative of this approach. All of them are readily available on the Google Marketplace.
Convertigo Introduction
The online availability of data and tools in the cloud is not always enough in an enterprise context. On the one hand, the Web 2.0 implies that users contribute to the information system. On the other, enterprise computing implies constraints that mainstream computing does not have.
Enterprise mashups
Enterprise "mashups" offer a solution to these limitations. They combine ideas from the web 2.0, from SOA and from enterprise computing. They can be roughly defined as composite applications, connected to the IS (both internal and external), that the users set up themselves. They are equivalent in their design to the more classical mashups that everybody already uses (like iGoogle or Netvibes for instance), but they can combine general public widgets and widgets connected to enterprise applications (CRM, ERP, SCM, SFA). Mashups go beyond what portals can offer because widgets are able to interact with each other and thus can automate workflows and data transfer.
Third-Party Extensions
Most enterprise applications, however, were not designed to be integrated in mashups. Mainframe applications or older web applications rely mainly on older protocols defined long before SOAP or REST and moreover they don't make their data available in any structured format based on XML. Connecting to these enterprise systems requires both knowledge of the topology of the IS and development skills (web programming, project management, configuration management). This is why Convertigo proposes two "studios" that are briefly presented below.
Convertigo solutions
The first studio targets corporate developers who can connect to existing applications, even those that publish neither any APIs, nor any structured data. This studio allows capturing, filtering, and transforming data and associated business logic. It allows publishing these resources as widgets that can be integrated in these mashups or as web services that any SOA applications can consume. The second studio, targeted at business users, allows them to compose various widgets into enterprise mashups. No technical prerequisites are needed, widgets can be combined graphically. The Google Apps suite can use these widgets and the web services published by Convertigo to integrate them with enterprise applications. This can be done by synchronizing the information between the enterprise IS and the Google Apps. It can also be integrated via iGoogle (using Convertigo widget) or even via new, specific applications developed with Google's frameworks and tools.
Example use cases
Let us use a concrete example to illustrate these possibilities. Convertigo is currently used in a large European insurance company, which chose Google Apps as a collaboration platform. It helps this company to synchronize an idea management application with Google Docs.
[ 184 ]
Chapter 11
Browser
Idea management
The idea-management package is a web application offered in SaaS mode by a software vendor. This application has no integration APIs.
The Convertigo solution is deployed in the Cloud as well and thus maintains the coherence of the architecture. One of the advantages of the Convertigo solution is that it enables access to the idea management package from mobile devices.
Browser
Idea management
One of the advantages of the Convertigo solution is that it allows connection to the idea-management package using mobile devices
[ 185 ]
Third-Party Extensions
Using the Convertigo Studio made it possible to capture the needed information in the pages of the package and to make them available in the Google Apps as new web services (as seen in the following screenshot). The system provides two-way functionality because the Convertigo technology can also work in update mode. This is possible because Convertigo maintains a connection with the original application from which it captures the screen contents. This way, all business logic and data validation remain fully operational. Finally, the captured data is assembled in an enterprise mashup that gathers several widgets related to promoting new business ideas, and that allows collaborative thinking based on them. This is actually a brainstorming platform in the cloud.
The information gathered is assembled in an enterprise mashup that aggregates several widgets
In the future, Convertigo will offer a component library that wraps Google's API in order to generate mashups even more quickly by combining these Google components with other public or commercial widgets while supporting interactions and complex navigation between all these components. URL: http://www.convertigo.com/
[ 186 ]
Chapter 11
RunMyProcess Introduction
RunMyProcess is an easy-to-use workflow solution integrated with Google Apps. Whether the goal is to define workflows, to create user interfaces, or to integrate with other systems, all tools offered by RunMyProcess are graphical and intuitive. RunMyProcess is a partner with Google Enterprise and the solution is available on the Google Apps Marketplace. To summarize, using RunMyProcess, it is possible to do the following tasks without any prior technical knowledge: •
Add customized applications to Google Apps
•
Design and deploy customized gadgets
•
Add reporting gadgets in Google Apps
•
Visualize and interact with a set of tasks directly from Gmail or from Google Sites or any other Google Apps
•
Enter data resulting from a process into a Google Spreadsheet
•
Retrieve or send data to or from CRM or ERP systems
•
Automate actions within Google Apps services securely
More than 1000 connectors are available on the platform to speed up application design. They connect RunMyProcess with a range of SaaS products such as the Google Apps and with other services like NetSuite, Zoho, or Amazon CE2/S3. Other services are available such as sending SMSes, generating Office files, or scoring services. Particular attention was given to security and therefore RunMyProcess offers a large range of authentication solutions: •
An SSO solution, which uses SAML 2.0 (see Chapter 8 on that topic) will prove useful provided a central enterprise directory is available
•
Open ID allows users to use their Google Apps credentials to access any RunMyProcess application
•
The OAuth protocol, which is integrated in RunMyProcess, makes it possible for Google Apps to read data from the tool and display it in Google gadgets
[ 187 ]
Third-Party Extensions
Finally, the 2-legged OAuth protocol, strengthened with the security policy that is specific to RunMyProcess, enables processes to access the Google Apps securely without the need to disclose the user's credentials. Each of these solutions addresses specific needs but they can be used jointly.
Example use cases Case 1: SaaS workflow
The first use case of RunMyProcess is the setup of a validation workflow for a document before it is published on a website. The document we are talking about is a Google Docs document and its publication, after validation, takes place in Google Sites. For this purpose, a Google gadget allows selection of the pages and files to validate before launching the workflow.
A Google gadget that allows selection of pages and files to validate
Case 2: SaaS synchronization
The second example of an application of RunMyProcess is an automatic synchronization between the Google Calendar and an Oracle CRM on Demand agenda, that is managed through a Google gadget placed in Google Apps.
[ 188 ]
Chapter 11
Automatic synchronization between the Google Apps calendar and the Oracle CRM on Demand calendar
Case 3: Application gadget
Another use case could be visualizing aggregated data from several sources in the IS in Gmail.
Data visualization in Gmail
RunMyProcess is distributed on the Google Apps Marketplace. URL: http://www.runmyprocess.com/content/solutions
[ 189 ]
Third-Party Extensions
Cordys Introduction
Cordys is another workflow tool that allows automation of business processes and assembly of "mashup" web applications (the section devoted to Convertigo gave a short presentation of this category of tools). The exchange of information among team members can be structured and this will result in more reliable process execution. Cordys allows you, for instance, to build forms that participants in a processes can fill out, and then to monitor the execution of the whole process. The recurring tasks that might benefit from such automation are numerous. Let us mention just the most usual ones: making expense reports, entering activity reports, applying for leave as well as all processes involved in checking or approving any of these. The Google Apps are used here as building blocks of the system: • • •
Google Spreadsheets circulate in a workflow Applications are built using Google Sites The integration of the various process tasks is implemented via Gmail
Describing a workflow with BPMN in Cordys
[ 190 ]
Chapter 11
Example use cases
The Cordys workflow tool is currently used in the following areas: •
For communication between service providers: white labels, XaaS mashup networks
•
In manufacturing: combined with Google Apps, the Cordys tool is used to replace 7,000 specific Lotus Notes applications, used by 30,000 employees of a large enterprise
•
For supply chains, it allows real-time tracking on a smartphone
•
For local business, it allows small and large companies to integrate within a supply chain using ERP features
•
The design of utilities such as smart counters in the Cloud
•
For networks of local pharmacies it can help systematize communication between pharmacists and their customers for anything related to recurring prescriptions
CORDYS is distributed on Google Apps Marketplace. URL: http://www.theprocessfactory.com/
Summary
This chapter described three tools that are representative of the extensions available for the Google Apps. Two of them are currently available on the Google Apps Marketplace. Among those tools presented, two are related to enterprise mashups (Convertigo and Cordys) and two are related to enterprise workflows (Cordys and RunMyProcess).
XaaS = Anything as a Service!
[ 191 ]
Part 4 Managing a Migration Project to Google Apps Choosing a Migration Method The Pilot Project Performing the Migration
Managing a Migration Project to Google Apps After a detailed presentation of Google's SaaS offering in the first three parts of the book, one important question remains: which strategy is the best suited for moving an existing system towards this new model? In this last part, we attempt to answer this question and provide readers with best practices that ensure the success of such a project. These three chapters are aimed at any project manager or technical leader who is in charge of organizing or managing such a migration project. Our approach is essentially based on pragmatic thinking and real-life experience with migration projects. To start with, Chapter 12 describes and proposes various possible strategies depending on the type of company. There are actually five strategies; they primarily depend on the number of employees, on geographic dispersion, on the existing mail solution, and on which Google Apps are required. The five strategies are ranked from the simplest to the most complex. Each one defines which tasks should be planned: preliminary study, pilot project, setting up user support, migration itself, and advanced integration with the IS. Finally, we summarize which strategies we believe are optimal for eight different types of companies. Chapter 13, The Pilot Project focuses on the pilot project, which is often a key to a successful migration. This is a full-fledged project whose role is to define the perimeter. Just as for any other project, it is important to identify and prioritize the requirements. The Google Apps offering is quite broad and it certainly makes no sense to cover all aspects in a pilot project. A set of questions to ask in order to select the most significant topics to deal with in the pilot project, are given in this chapter. Another important aim of the pilot project is to let users try out the solution. This often turns out to be very important because it will help define an appropriate level of support for users once the migration has been completed. One last motivation for the pilot project is to check the technical feasibility of both the migration operations and the advanced integration solutions with the existing IS.
Chapter 14, Performing the Migration describes the course of an actual migration and which Google tools are available for data recovery from existing mail, calendars, and contacts. In the interest of brevity, we shall concentrate on the two market leaders, namely Microsoft Exchange and IBM Lotus Notes. In the Microsoft world, there are tools that allow an end user to take charge of the migration of his own data and we present those, too. Finally, we provide tables which summarize which versions of which mail systems are supported by Google's software.
Choosing a Migration Method This chapter aims to present various migration strategies to the Google Apps. For this purpose, the first section describes a number of technical and organizational criteria that we shall use to characterize a company. They will come in when we define the optimal strategy. Later, we define five strategies and describe them in detail. Finally, in the last part, we examine eight types of companies, among the most usual ones, for which we propose one or more strategies while giving the motivation for our choices.
Identifying the company profile Size of the organization
The number of users to migrate, itself related to the size of the company, is the fundamental parameter in the choice of a migration strategy. It is not hard to understand that migrating 50 users is quite different from migrating several thousands of employees. From this point on, we shall consider for simplicity's sake that the number of employees in the company is the actual number of users to migrate to Google Apps. Thus, we propose the following standard classification: •
Very small companies, which have fewer than 10 employees
•
Small companies, which have between 10 and 250 employees
•
Middle-sized companies with 250 to 2,000 employees
•
Large companies with more than 2,000 employees
Choosing a Migration Method
Contrary to popular belief, the length and complexity of a migration and a pilot project is not necessarily linked to the number of users to migrate. The steps of the migration project, however, are related to this parameter. For example, it is quite likely that a large company will ask for change management support for their users, whereas a smaller high-tech start-up can probably do without such support. In the former case, setting up a user support team and creating Google Apps ambassadors should be planned.
Geographic dispersion
Another important parameter for the choice of a migration method is the degree of geographic dispersion of the messaging infrastructure. Here are a few examples of geographic dispersion for various types of companies: •
Companies and branches sharing a single mail server for the whole IS
•
Companies and branches sharing a single mail server, which is outsourced to some provider
•
Companies having one dedicated mail server for each subsidiary
•
Companies having one dedicated mail server for each international subsidiary
Geographic dispersion usually dictates a subdivision of the migration process. This should be planned early on. The SaaS migration will completely eradicate the dissemination of mail servers. The existing organization and responsibilities will obviously be impacted as well. One simple solution could be to designate, for each site, a person who will assist with the migration. His or her mission will be to ensure the coherence of the migration for that site.
Targeting the appropriate population
Within this context, we propose the following categorization of end users: •
End users who are largely autonomous with technical matters (for example, employees of a software engineering company)
•
End users who are not autonomous but are motivated technically (imagine a company that has recurring mail problems, like unavailability, and so on)
•
End users who are not autonomous and are poorly motivated (companies for which reducing costs is a priority and for which the IS is not part of the core business) [ 198 ]
Chapter 12
To start with, let's first note that the migration might not necessarily concern the whole company but only a subset of the users (department, subsidiary, entity, and so on). Once this population has been identified, the degree of autonomy of concerned users should be evaluated. Tasks that can be assigned during the migration will depend on this evaluation. Put another way, the amount of technical and logistical support, as well as training that they require will depend on this evaluation. If the technical autonomy of users is good, designating ambassadors remains optional and the user support can be more lightweight. If users have significant autonomy, it will be possible to: •
Industrialize the migration
•
Delegate most of the migration to the end users
•
Make the support and training phases optional
There are large companies, whose size exceeds 10,000 employees, which delegated the migration to their end users (for example, account configuration, importing existing data, and so on). Still, such a situation remains rather uncommon. Human factors should not be neglected. A migration involving a population of mostly recalcitrant users will obviously not take place in the same way as one where people take a proactive stance with respect to change. One thing should be clear though: the migration to Google Apps can ultimately be justified to users only by increased functionality, as compared to the status quo. The pilot project, which will be the topic of Chapter 13, The Pilot Project, can turn out to be very useful for detecting inertia among users and taking appropriate measures.
Existing mail
The last parameter is the type of the existing mail system. The principal platforms available in the electronic messaging market today are: •
Microsoft® Exchange Server
•
IBM® Lotus Notes
•
Open source (ex: Round Cube, Squirrel Mail…)
Each platform can be hosted in two modes: •
Within the company, the hosting is said to be "on-premise"
•
By a service provider, the hosting is said to be "hosted"
[ 199 ]
Choosing a Migration Method
Both the mail platform and the hosting mode will dictate what tools should be used (see Chapter 14, Performing the Migration on that topic) and, all the more, the appropriate operating mode. In some cases, depending on the version and the existing configuration, it may be necessary to develop ad hoc software solutions, hence the importance of the experimentation phase (pilot project).
Expressing requirements Functional requirements
As was described in the second part of this book, the Google Apps offering is structured around two themes: •
Communication tools: Gmail, Google Calendar, Google Talk
•
Collaborative office tools: Google Documents, Google Sites, and Google Video
It is thus necessary to precisely qualify the requirements regarding these two topics, to identify which applications will actually be made available to users. Depending on the needs or constraints of a company, it is sometimes better not to enable some of them: Google Talk, Google Video, or even Google Documents, and so on. Usually, choosing among communication and office tools in Google Apps is rather obvious. The choice might be more delicate for other Google services, though. Among these, the following might prove particularly useful: •
Global indexation of data in the IS using Google's dedicated search tool: Enterprise Search Appliance
•
Reporting through Google Spreadsheet and the Secure Data Connector
•
Managing enterprise workflow through third-party extensions from the Google Apps Marketplace, and so on
To this, one should add the data-transfer tasks, which means importing existing data into Google Apps. For each Google application, this will determine the workload during the preliminary analysis phase as well as during the actual migration phase. A lack of data transfer requirements might make the pilot phases superfluous. On the other hand, importing data (because the mail system is obsolete, has an exotic configuration…) could imply specific, ad hoc developments. Although a number of tools are provided by Google, they won't necessarily suffice in all situations.
[ 200 ]
Chapter 12
Non-functional requirements
Advanced integration of the Google Apps in the IS often implies planning a larger migration project. One or more additional steps can be required. As examples, let's mention the following projects: •
Setting up a Single Sign-On mechanism that will provide automatic authentication on any desktop (on SSO issues, we refer you to Chapter 8, Federated Identity and SSO).
•
Developing specific applications (for example advanced contact management). These applications can both interact with the IS through Google APIs or be deployed directly on the Google Apps Engine infrastructure.
•
Multichannel access pilot: Although multichannel access is native in the Google Apps platform, it might still need an experimental phase, for mobile terminals.
•
Integration with an intranet portal that incorporates Google Apps' data through dedicated widgets.
Security and availability of tools are among the most often quoted assets which motivate the SaaS model. However, during a migration project, these two perceived advantages might sometimes be put to the test. One priority of the pilot project is to mitigate and, when possible, eradicate any concerns related to these topics. Finally, depending on the desired integration level, it could be necessary to anticipate a rollback plan, which warrants a phase of its own in the migration project.
The migration strategy Projects, phases, and strategies
The various steps of the project are named phases, and they usually comprise several tasks, which we will describe below. Each elementary phase has a goal that determines the nature of the tasks attached to it. The succession of elementary phases determines the succession of the tasks and hence the overall strategy. The duration of phases thus depends on the duration of the tasks, whether they are realized sequentially or in parallel.
[ 201 ]
Choosing a Migration Method
The challenge is therefore to determine the optimal strategy while taking into account the following criteria: •
The company profile (size, dispersion, type of population)
•
The set of functional and non-functional requirements
•
The existing mail system
The elementary phases Performing the preliminary study
The preliminary study remains the essential phase of a migration, whatever the strategy is. Its goal is to precisely identify the company profile, its functional and technical requirements, as well as the features of the existing mail system. It also aims to identify the dependencies on the IS and should anticipate advanced integration tasks. It will conclude with a detailed schedule of the actual migration. Its duration will depend, for the most part, on the number of people involved in the project and the number of topics to handle.
Designing a pilot
The pilot phase enters the picture when the feasibility of some technical solution needs to be checked or when the solution is a vital issue for the company. It is also important when the coaching of future users must be organized. This phase is quite common for mid-sized or larger structures or when advanced integration with the IS is considered (for example, Single Sign-On, industrialization of data transfer from archives, integration with an enterprise portal, establishing links with enterprise workflows, and so on). Chapter 13, The Pilot Project contains more details on the pilot phase, which is its topic.
Training users
The training phase is organized in sessions, which may take two forms: •
Direct training of users. This phase is usually rather short: fewer than five sessions, one day each, to which 20 to 30 people at most will attend. Beyond this figure, it is probably better to nominate ambassadors. The sessions present the general nature of the new solution and the features and tools that have been selected for deployment. These sessions should be developed taking into account the specificities of the company (mobility, off-line mode, and so on). [ 202 ]
Chapter 12
•
Training of "ambassadors". The "ambassador" sessions cover more material but are for a smaller, informed audience. These ambassadors will assist regular users with any questions related to the Google Apps for the first month after the initial deployment. They can be a substitute for the traditional help desk and even obviate the need for users to receive training.
Setting up User Support
The support phase is for helping users, and can be conducted simultaneously with the pilot and migration phases. It is particularly useful when users have a low level of technical autonomy. This phase is also the opportunity for the existing help desk to gain expertise on the Google Apps. Organizing support is linked with nominating ambassadors. These are employees who were specially trained for the Google Apps and in charge of providing on time help to users.
Setting up a rollback plan
Setting up a rollback plan includes defining all tasks necessary to roll back from the Google Apps to the previous solution. One important aspect of this plan is to know exactly how to remove any data hosted in Google's datacenters. This includes, in particular: •
Check the feasibility of recovering all data processed by the Google Apps. Useful hints for this purpose can be found on the site of the Data Liberation Front that we mentioned in Chapter 2, Why Trust Google?.
•
Define rollback scenarios for each Google App.
The aim here is not to define preventive actions that could be taken if a problem occurs but rather to anticipate an inverse migration plan. In a sense, this phase could be conceived as an extension of the pilot phase because the plan should be tested before the final migration. This phase is often integrated in one of the tasks of the pilot phase.
Performing advanced integration
Advanced integration usually happens only after the completion of the primary migration steps which involve mail, calendar, and contacts.
[ 203 ]
Choosing a Migration Method
Advanced topics, which are identified in the preliminary study, usually include such topics as: •
Setting up Single Sign-On
•
Setting up a CRM
•
Using APIs
•
Using data extracted from internal repositories for reporting in Google spreadsheets
•
Integration with the enterprise portal
•
Linking to enterprise workflows, and so on
The length of this phase greatly depends on its scope.
Performing the migration
The actual migration phase is the last one (except the advanced migration). Its aim is to have all users working with the Google Apps, following previously validated procedures (see the pilot project, training, and so on). Paradoxically, the migration is one the shortest phases. In most situations, communication applications are available within 48 to 72 hours. This includes data transfer to Gmail, Google Calendar, and contacts. Chapter 14, Performing the Migration is entirely devoted to a detailed description of this phase and includes a review of the tools available on each platform.
The five types of strategies
The five strategies presented here are sorted from the simplest to the most complex.
"Flash" strategy
This is a minimalist strategy that is well-suited for smaller organizations that have a technically autonomous population and for which the dependency on the IS remains weak. Study
Migration
"Flash" strategy
[ 204 ]
Chapter 12
"Do It Yourself" strategy
This is a strategy for small organizations whose population should be trained to take charge of the migration. Training
Study
Migration
"DIY" strategy
"Light" strategy
This is a strategy for small to mid-sized organizations. The data migration is usually handled by an administrator; only some specific tasks are left to the end users, such as migrating mail archives, for instance. The lack of autonomy of users is balanced by their small number. This can usually obviate the need to set up a helpdesk. User training should thus include migration tasks. This strategy is less suited to multisite configurations, but is appropriate when the dependency on the IS is not too strong. This last point could in some cases justify setting up a pilot phase. Study
Training
Pilot
Migration
"Light" strategy
"Standard" strategy
This strategy is adapted to mid-sized or larger structures when dependency on the IS is weak to medium. Most often, this implies setting up a pilot. The technical autonomy of users and their number imply organizing a dedicated support infrastructure. Resorting to ambassadors is an alternative which can also be considered as a complement to the helpdesk, if the number of users is large. Study
Pilot
Support
"Standard" strategy
[ 205 ]
Training
Migration
Choosing a Migration Method
"Advanced" strategy
This strategy is adapted to larger organization (international subsidiaries, and so on). The dependency on the IS is significant and necessitates setting up a pilot and specific phases devoted to critical and complementary tasks. On such a scale, anticipating a rollback and reversibility plan is particularly important to mitigate the risks. The large number of mostly non-technical users requires setting up a helpdesk and designating Google Apps ambassadors: Study
Reversibility plan
Pilot
Support
Training
Migration
Advanced integration
"Advanced" strategy
Which strategy for which kind of organization?
We now list eight important types of organization for which the essential elements determining the strategy are described.
Organization of Type 1 (OT1) • • • • •
Very small organizations of no more than 10 employees A single geographic site Open-source mail server, hosted offsite Target population is technically oriented No advanced needs besides mail and calendar
These are mostly small, niche companies specializing in new technologies (software engineering companies, start-ups, and so on). Flash migration is particularly well adapted because the population is technically autonomous. Training and support are in this case unnecessary. Furthermore, the small number of users favors a thorough delegation of the whole migration to the users themselves, from the data transfer to the configuration of the various tools.
Organization of Type 2 (OT2) • • • • •
Very small organizations of no more than 10 employees A single location Open-source mail server, hosted offsite The target population has a non-technical profile No advanced needs beyond mail and calendar [ 206 ]
Chapter 12
These are small organizations whose business is not related to new technologies (for example, craftsmen, retail stores, associations, and so on). Here again, the small number of employees allows them to take charge of the migration themselves. A training phase should be planned, however.
Organization of Type 3 (OT3) •
Small to mid-sized companies with upto 50 employees
•
A single location
•
Proprietary mail system (Exchange/Lotus notes), hosted offsite
•
Non-technical target population
•
No advanced needs beyond mail and calendar
These are mid-sized companies whose business has no relation to new technologies (for example small industry, construction and civil engineering works, and local authorities). The small size of the population allows the delegation of migration to the users themselves, provided some initial training is offered. Let us note that moving to the "Light" strategy is usually motivated by the need for a pilot phase. This phase makes the migration to the new solution smoother, thanks to a changemanagement policy.
Organization of Type 4 (OT4) • • • • •
Small to mid-sized companies with up to 50 employees A single geographic site Proprietary mail system (Exchange/Lotus notes) hosted on-premise Most users have a technical profile No other needs than mail and calendar
These are mid-sized organizations with users who have, for the most part, some technical autonomy. In principle, a "Flash" migration could be performed with minimal training and preparation. What could lead to choosing the "Light" strategy instead is the need for a pilot strategy required for validating the technical feasibility of some tasks.
Organization of Type 5 (OT5) • • • •
Mid-sized companies of up to 500 employees Up to three locations Proprietary mail system (Exchange/Lotus), hosted on-premise No specific needs beyond mail and calendar [ 207 ]
Choosing a Migration Method
These are mid-sized organizations with no specialization in computing. They have several geographic locations and have their own mail system. The absence of technical skills and the number of employees would in principle favor the "Light" approach, which implies preparing for the migration through a pilot project and user training. Adopting the "Standard" strategy, however, is most likely because it adds a helpdesk. The selection of ambassadors, planned in the standard strategy, remains optional however, because the number of employees is not large enough.
Organization of Type 6 (OT6) •
Mid-sized company with up to 2,000 employees
•
10 locations
•
Open-source mail server, hosted offsite
•
Target population has technical skills
•
No advanced needs beyond mail and calendar
These are mid-sized organizations whose population has good technical autonomy. They have several geographic locations and run their own mail servers. On such a scale, this is the only case where the "DIY" strategy is still possible, meaning that training and user support can be left out. However, adding the pilot phase makes sense to validate the technical feasibility of some tasks (connecting to an enterprise directory, for instance).
Organization of Type 7 (OT7) •
Mid-sized company with up to 2,000 employees
•
10 locations
•
Proprietary mail system (Exchange/Lotus notes), hosted offsite
•
Target population has no technical skills
•
No advanced needs beyond mail and calendar
These are mid-sized organizations without technical specialization. They have several geographical locations and have their mail servers outsourced. The most reasonable strategy is the standard one.
[ 208 ]
Chapter 12
Organization of Type 8 (OT8) •
Very large organizations with more than 10,000 employees
•
At least 10 international locations
•
Proprietary mail servers (Exchange/Lotus), hosted on-premise
•
Target population with no technical skills, for the most part
•
Advanced integration needs: SSO, CRM, reporting
These are large organizations with no specialization in computing. They have several locations and own their mail servers. They often have advanced integration needs for the Google Apps. The Advanced approach is the best solution. Without the advanced integration needs, the Standard approach could be sufficient.
Conclusion
For each of these types of organization, the following table summarizes the most usual strategies that can be applied for a migration to the Google Apps: Flash OT1 (10 employees)
DIY
þ
OT3 (50 employees)
þ þ
Advanced
þ þ
OT5 (500 employees) OT6 (2 000 employees)
Standard
þ
OT2 (10 employees) OT4 (50 employees)
Light
þ þ
þ
þ
OT7 (2 000 employees)
þ
OT8 (10 000 employees)
þ
[ 209 ]
þ
Choosing a Migration Method
Summary
The famous saying: "Know yourself!" probably best summarizes the first part of this chapter. Indeed, before seriously thinking of migrating, the first task is to precisely assess the existing tools and needs. The profile of an organization is defined by its size, its geographic dispersion, and the type of population concerned by the migration. This is the first parameter on which the migration strategy depends. The second parameter is simply the type of the existing mail system. Last but not least, there are the needs for the messaging system. These needs cover both the features of the existing system, which should be preserved, and the expected improvements. Having identified these three sets of parameters, the selection of an appropriate strategy can proceed. Needless to say, complex issues such as the migration of a messaging system cannot be captured in a simple algorithm that you can just "run." For this reason, this chapter chooses to define five clearly identified strategies and to retain only eight types of organization. The chapter concludes, logically, by proposing one or more strategies for each of those eight categories.
[ 210 ]
The Pilot Project Before the actual migration to Google Apps, there is often a technical and organizational phase called the "Pilot Project". This chapter presents the principal issues related to this pilot project. The first part deals with organizational matters. The second part more concretely explains how to implement it. Finally, the chapter concludes with a proposal of how to evaluate the results of this experimental phase.
Why a pilot project? The issues
Adopting a new tool generally includes an experimental phase. Many things have to be done simultaneously: to evaluate the benefits of the new solutions, to progressively train the users on the new solutions, to identify the impacted use cases and, finally, to define a migration plan that will lead from the current situation to the target situation in a smooth way. This experimental phase is a project unto itself and this is what is called the pilot project.
The Pilot Project
The pilot project is not a simple functional and technological demonstration whose aim is to display the panoply of existing features and prove the technical feasibility of the migration. Its primary purpose is to come up with a changemanagement policy and to identify the infrastructures and the procedures that will be impacted. Even if these changes are usually more in terms of configuration than the development of new products, the subject remains touchy. Within a professional context, you should keep in mind that acting on the messaging system will have an impact on a large number of users. Losing messages, incorrect addressing, and spam are all things to avoid. Put simply: the success of the pilot project strongly correlates to the success of the migration as a whole.
Scheduling
There exists no strict rule for the length of a pilot project; it can vary from two weeks to two months, roughly. Contrary to what you might expect, the length of a migration project will depend more on the scope than the size of the organization. The population of pilot users is usually restricted to a subset of no more than 20 individuals. This is enough for a representative sample of the user population, as disparate as it may be. Another important element affecting the schedule is the expectations held of the pilot project. Asserting the technical feasibility of the migration is not tantamount to preparing the whole migration. This confusion, however, frequently occurs. Checking the feasibility of rolling back the migration for a single user is certainly not equivalent to industrializing this rollback at a larger scale. For each topic dealt with in the pilot, you should precisely assess the expectations and deduce the time required to achieve them. Just as for any other computing project, the pilot project consists of defining the triad: scope, planning, and cost. The remainder of this chapter is thus devoted to providing concrete elements for organizing this type of project.
Defining a scope
Defining the scope of the pilot project, just as for any migration project, is essential. This scope should be representative of the actual target while only relying on a small sample of the population, a partial set of features and, most often, a technical environment that is not an exact copy of the target environment.
[ 212 ]
Chapter 13
In the specific case of an experiment with the Google Apps, defining the scope means choosing: •
The set of Google Apps to experiment with, the most customary being Gmail and Google Calendar.
•
The subset of representative users. These are sometimes called pilot users.
•
The appropriate amount of training and support to provide to users to optimize their implication level.
Another important point is the context within which users are testing the Google Apps. For the result of the pilot project to be significant, using the Google Apps should happen in the most realistic way possible. In other words, pilot users should use their new tools on a daily basis to communicate and collaborate with their co-workers. Indeed, as experience shows, isolated experiments are seldom significant or useful. Using Google Apps "no matter what" should be the users' motto during the pilot phase, especially if the existing system remains active.
Choosing the applications
While selecting such tools as Gmail and Google Calendar is commonplace or even trivial, it is not so obvious to choose among the remaining items in the "galaxy" of Google Apps. Google Talk can be integrated as an instant messaging tool. If the experiment also involves collaboration, the candidate applications will be Google Document, Google Sites, and Google Video. Advanced integration with the existing environment can require using SSO services, Enterprise Search Appliance, or developing specific applications using Google APIs. Mobile usage, on the other hand, doesn't require much thought or testing, because the Google Apps platform is natively multichannel and continuously improving to address evolving mobility needs. The most important questions, though, are related to the effort required to transfer data to the Google Apps. Here are three questions to ask for each application: •
Should all existing data be transferred?
•
Should users have access to mail history and to existing calendar events so as to assess the features and possibilities of the Google Apps?
•
Does the absence of such information as the postal address in the contacts prevent properly evaluating the solution?
[ 213 ]
The Pilot Project
These questions are meant as hints to simplify the pilot without penalizing the experimentation itself.
Advanced Integration
Collaborative Office Suite
Unified Messaging System
Apps that selected for integration in the pilot project
Choosing pilot users
One key to a successful pilot is the choice of pilot users. Obviously, a good choice will be one which includes a representative sample of the whole target population. One can choose a user by subsidiary, by department, by business line, or by geographic area. One other advantage of a diverse selection of users is that it allows testing collaborative aspects of the solution. One could select, for instance, users from various divisions in the company, working together on a project or accustomed to working together. If, on the other hand, Google Apps is targeted at a specific population in the company, it is essential to have users from that population participating in the pilot. One such example is users who don't have any mail yet. Beyond the criteria just mentioned, there are also criteria related to the experimental phase itself. For instance, it is certainly a good idea to include those users who already use Gmail for personal purposes. The support they will need will obviously be less than that required for novices.
[ 214 ]
Chapter 13
The motivation of pilot users should also be taken into account. Rather than imposing a software change on some people selected without their knowledge, it might be a good idea to take a quick poll to see who is interested in the subject.
Extending the scope
The obvious purpose of a pilot project is to organize the migration and to get feedback from users. Besides these two points, it will prove useful to include the following two topics.
The user-identity lifecycle
Going Google raises the question about the lifecycle of user identities. It is quite common to find several identity directories in the same information system. For example, you can find a human resources directory and simultaneously an account directory, and so on. When using the Google Apps, this kind of information is outsourced. In other words, how do you manage efficiently and in detail Google Apps account creation and update or deletion of a profile in the case of a resignation or firing? Particular care should be taken in order to prevent former employees from accessing their professional mail once they've left the company. The nature of the data stored in the Google Apps has an impact on which strategy to adopt. Managing passwords is obviously quite different from managing phone numbers or postal addresses. Different data don't require the same level of reliability. In many cases, the additional archiving service from Postini (see Chapter 5) can certainly answer these kinds of needs.
Managing external mailing lists
Mail systems usually include sharing features such as mailing lists. What we mean by mailing list is a group of internal or external mail addresses, or both, accessible to selected users of the domain, without the assumption however that they manage the list themselves. An example of a mailing list could be a list of "gold" clients that only salespeople can access. The notion of "group", which can be managed for Google Apps, covers precisely this kind of need (see Chapter 7). However, for the time being and without any further extensions (check the Google Apps Marketplace), managing the visibility of groups is possible only programmatically through the APIs. [ 215 ]
The Pilot Project
Accessing external contacts using a third-party enterprise directory (LDAP) is a common functionality of desktop clients such as Outlook or Thunderbird. It is, for instance, possible to access the mail addresses of employees of a subsidiary or of a partner. Gmail however does not propose access to this kind of contact; it is imperative that they are stored in the repository of the Google Apps domain. Here again, the Google APIs allow retrieving all required information automatically from external sources.
Access channels
Adopting Gmail offers new possibility for accessing mail. Provided an Internet access is available, mail, contact, and events are accessible from anywhere. Mobile access to mail should be included in the strategy, too. This last topic can open new perspectives and sometimes even bring the existing infrastructure into question. For example, let's mention the Blackberry offering, which dominates the market and which bundles client terminals, software to be installed on the enterprise mail server, and specific mobile operator subscriptions.
The authentication mechanism
The pilot project should also help define the target authentication mode and test its implementation. This choice, in particular, is related to the ease of access to the Google Apps. However, its criticality being low, this decision can be postponed. Keep in mind that the bare minimum for a Google Apps user is not having to remember yet another login/password pair. These should be synchronized with the enterprise directory. This can be achieved with the Google APIs. Setting up an SSO mechanism, which totally automates and streamlines the authentication process, is the ultimate solution (see Chapter 8 for more details).
Transferring archives
The migration of archives involves mail stored outside existing mail servers by users themselves. This is a common practice, because of lack of storage space on servers. Archives are large files whose format is proprietary (.pst for Microsoft Outlook, for instance). The pilot project is probably the best occasion to determine whether mail archives should be imported into Gmail or not. If such is the case, it might be necessary to install some specific software on each desktop.
[ 216 ]
Chapter 13
Here are the different strategies available, in order of increasing complexity and impact on the pilot project: •
Don't import anything into Gmail: a dedicated reading tool should remain on each desktop or at least in the company. Obviously, there is no impact on the pilot in this case.
•
Importing archives on demand (by the users themselves) implies choosing the tool and the procedure users will apply. This should be assessed by the pilot users.
•
Industrialize the importation of archives: this requires a substantial amount of work, which most often implies automation of tasks otherwise managed by users. The impact on the pilot project is significant.
The TCO of the target solution
One of the major goals of the pilot project is to estimate the real cost of owning the Google Apps. Experience shows the pilot project often reveals which tasks are needed during the final migration. One example is the merging or syncing of several user directories, which is a prerequisite to authentication delegation (see Chapter 8). The TCO includes all of the following: •
The cost of Google Apps licenses and extensions (Postini, and so on)
•
The cost of the technical migration, which includes the preliminary work (the pilot project) and the tasks for the actual migration
•
The cost of user training and support
•
The cost of project management by the IT department
•
The cost of external services (for example, opportunity study, level-2 user support, and so on)
•
The costs associated with adapting the information system, such as changing mobile subscriptions or the installation of new SSO servers, and so on
Note that the TCO is necessary to compute a realistic ROI estimate.
TCO: Total Cost of Ownership ROI: Return On Investment
[ 217 ]
The Pilot Project
The rollback and reversibility mechanisms
Any migration should come with a rollback procedure. This amounts to defining the tasks to perform in case of failure during the final migration. It would certainly not be admissible to leave users without mail or lose data after a grid or network failure. This rollback mechanism is not to be confused, however, with the reversibility plan. Reversibility refers to the ability to switch back, after an extended use of the Google Apps, to the old mail system which, in a way, is closer to an inverse migration. Reversibility guarantees that the system is not bound forever to Google Apps. This primarily implies being able to extract all data from Google's datacenters. Addressing these kinds of issues is part of the pilot project.
Implementing the pilot project
Shown in the following figure are the standard steps of a migration to Google Apps: Subscription User creation Service activation Delivery configuration Enrichment
Stepwise implementation of the pilot
Signing up for a Google Apps account Choosing a domain name
The very first thing to do is to subscribe to a Google Apps domain and to associate it to an existing domain (ex: mycompany.com) and not to, say, a test domain dedicated to the pilot project (ex: mypilotproject.com). We shall see later that this has no impact on the existing infrastructure (mail, DNS declarations, and so on). The subscription URL is currently http://www.google.com/a, and the "a" at the end designates the applications universe at Google. The outcome of this step is the administrator credentials for the Google Apps domain. The service is however not yet active. Indeed, for obvious security reasons, Google first needs to check the actual ownership of the domain name declared during the subscription process. [ 218 ]
Chapter 13
Here are the steps to follow: •
Connect as an administrator to the Google Apps configuration panel and initiate the process of checking the domain name.
•
Choose one of the checking methods. An assistant will provide the detailed steps to follow, depending on the method selected: °
Using an HTML form: this requires write access to the website hosted under the declared domain.
°
Using CNAME records: this requires write access to the DNS configuration for the declared domain name.
•
Launch the checking process from the configuration panel. This operation can take from 2 to 48 hours.
•
Once the check has been completed by Google, the status is displayed in the configuration panel and the service is available. Adding users can begin.
Choosing a version
Using services such as the APIs, mail routing, or web filters from Postini requires subscribing to Google Apps Premier Edition. The upgrade from the Standard version can be done at any time. The subscription includes a one-year trial period. We refer the reader to the introduction of Part 2 of this book for a detailed description of the differences between the various Google Apps versions.
Adding users to Google Apps
The next step is to create accounts for the pilot users. The required information is: first name, last name, username (prefix of the mail address), and password. Since this is an experimental phase, the number of users will rarely exceed 20 accounts. Several possibilities are available to create them: •
Manually from the Google Apps console.
•
Using a tool such as GAML.
•
Exporting and importing CSV files.
•
Programmatically, through the Google APIs. This method is certainly the best choice when the migration involves more than 3000 users.
[ 219 ]
The Pilot Project
Chapter 7 describes in detail user management in a Google Apps domain. Once the accounts have been created, it is possible to change the data of some users, in particular to grant them specific rights in the domain.
Enabling and configuring the Google Apps services The next step is enabling or disabling applications and services in the Google Apps administration console. Even mail will need to be enabled because by default it is disabled.
In the common case where the mail is part of the pilot project, the first recommendation is to adopt a so-called "dual delivery" strategy. The purpose is the redundant storage of mail, both on the existing mail system and in Gmail, without users having to change their address. There are two advantages to this solution: •
The old mail remains available and readable for the whole period of the pilot project in case Gmail should lack critical features or data
•
At the end of the pilot project, the rollback to the earlier situation is made easier as no data recovery task will be required
However, this strategy may not apply in some contexts, in which case you'll choose "direct delivery". This strategy applies both to incoming mail (that is, received mail) and to outgoing mail (that is, sent mail) and can be set up in two modes: either going through Gmail or using the existing mail server.
Dual-delivery via the Enterprise mail server
To implement the "dual delivery" using the existing mail server, no change of the MX�-record of the main domain is needed. For pilot users, you can configure sending a copy of each incoming mail to another associated address. These settings are defined directly on the mail server and are unfortunately not supported by all mail solutions. The domain of the associated address should however be associated to Gmail with a specific MX-record. The Google Apps can handle sub-domains as simple aliases of the main domain. Thus, using a sub-domain of the main domain will be the best choice for the associated addresses.
[ 220 ]
Chapter 13 domain.com
Internet
Existing mailing system
Mail reading Non pilot user
Internet
Pilot user
sub-domain.domain.com
Mail reading
Gmail
Original Mail Duplicated mail sent to sub-domain
The dual-delivery principle with an existing mail system
Dual-delivery via Google
To implement "dual-delivery" using Google, it is necessary to change the MX-records of the main domain and to define a specific routing rule in the Google Apps console. The propagation delay on the Internet of MX-record changes is up to 72 hours. Meanwhile, the messages are routed either to the old address or to Gmail. Beyond that, note that any mistake in these changes will imply mail service unavailability or even loss of messages. Fixing the problem could require an additional 72 hours. Finally, to revert to the initial situation, it would be necessary to change the MXrecord one more time. Existing mailing system
Mail reading
sub-domain.domain.com Non pilot user Internet
Internet
Pilot user Mail reading
Gmail domain.com Original Mail Duplicated mail sent to sub-domain
The dual-delivery principle using Gmail
[ 221 ]
The Pilot Project
Enhancing Gmail and Google Calendar
Depending on the scope of the migration, a number of applications should import all or part of the existing data. No doubt messages, contacts, and agendas are the primary data that should be imported. Migration tools will be described in Chapter 14. Numerous solutions are also available from Google's partners on the Google Marketplace. Users can thus be notified when their new communication and collaboration platform becomes available.
Evaluating the results of the pilot project Bringing support to users
The experimental phase is also the first opportunity to increase user buy-in. This is the reason why user training and support should already be planned in the pilot. The initial phase should teach the principles of the Google Apps solution. This step is essential, since the Google Apps cannot be used exactly like a traditional mail client and because its specifics are precisely what makes its strength. Users with no knowledge of the Google Apps and without prior preparation are not likely to become spontaneous advocates for the new solution: giving them adequate information and preparation increases the likelihood that they'll want to spread the good word later on. Training may be adapted to various populations depending on their needs. You might want to consider sessions of the following kinds: •
User training on Gmail and Google Calendar.
•
User training on Google Sites, Google Docs, and Video.
•
Administrator training for the Google Apps console.
•
Administrator training for the Postini services.
[ 222 ]
Chapter 13 Google Apps Administrator Program: •Deployment strategy •Administration basis •Console elements •Migration strategy and tools •Identity federation •Google Postini services
Gmail and Google calendar for users Program: •Gmail and Google calendar in Google Apps •Gmail in details •Instant messaging •Google calendar in details •Mobile acces
An example of training session for users and administrators
Many sources of information are available. Online help is available directly from within each tool, although it seems best suited to technically savvy users. There also exist numerous video tutorials for non-technical users.
Google's help center
The next level of support is provided by "ambassadors." These are users that have Google Apps expertise that they obtained either by taking a special training course or through prior use of the tools.
[ 223 ]
The Pilot Project
While the pilot project is going on, it is a good idea to organize work sessions to answer user questions. The sessions can be prepared easily by sharing a spreadsheet (see Chapter 4 for a presentation of the tool). Each pilot user enters the details of the problems he or she encountered in the spreadsheet. Ambassadors should try to qualify the user questions according to what relates to user interface and what are genuine defects. In this case, the spreadsheet can also be used to centralize the positive feedback from users (see the next section, devoted to the results of the pilot).
Example of a user scorecard as a Google Spreadsheet
Creating a more complete communication workspace is another possibility (FAQ, forums, wiki, mailing list, and so on). A moderator from the IT department should however monitor the platform to ensure it is working properly and also to identify the most active users and then rely on them to propagate information.
[ 224 ]
Chapter 13
Getting assistance from an integrator among Google's partners can help with the development of support capabilities. Google's own support is also available to anyone who has subscribed to the Google Apps Premium Edition. Internally
Approved service provider
Helpdesk / Ambassadors Collect feedbacks from users internal communication Qualification and sending of the requests to level 2
Support team
Interface Team
Google Regerent
Qulification for sending to level 3 Technical Team
Final users
Ask internal support with mailing list ou dedicated communication spaces Support level 1
Support level 2
Support level 3
Support organization with a Google approved service provider
Evaluating the results
The purpose of experimentation is to assess the level of user satisfaction in the pilot group. For this purpose, you should define a set of criteria and sub-criteria weighted with their importance and use them to evaluate the solution. These same criteria can be applied to the existing solution as a means of comparison. Here is a possible classification: "Features" designates the set of criteria and sub-criteria related to features. Ideally, the minimal coverage in terms of requirements is defined by the existing solution. Additional or missing features in the new solutions will count as positive or negative points in the final evaluation. Criteria should be weighted. "Usability" is about human factors, such as user experience or the quality of documentation. Most user feedback is on user experience.
[ 225 ]
The Pilot Project
"Reliability" refers to reliability and availability aspects. Google is committed to 99.9% availability of the Google Apps solution, which is equivalent to 8 hours unavailability in one year. In the event of unavailability of its services, Google is committed to compensating its customers. More detailed information on SLAs can be found in the introduction of Part 2 of this book. Google ensures the privacy of all communications between you and Google Apps. The data is stored in fragments in many servers, which increases privacy and safety. These issues were discussed in detail in Chapter 2. "Performance" includes criteria and sub-criteria such as response time and resource consumption. Evaluation of the solution using these criteria is usually the administrator's responsibility. Bandwidth consumption, storage space, and archiving abilities should be evaluated. "Supportability" covers criteria such as adaptability, maintainability, interoperability, or portability of the solution. The level of interoperability with other application in the IS should be assessed separately. The Google Apps solution offers a set of programming interfaces using standard protocols and architectures. These APIs facilitate integration and improve interoperability (XML, REST, and so on) between Google components and other applications. Furthermore, the Google Apps solution complies with standard authentication architectures (SSO, OpenID). Google takes full responsibility for the maintenance and evolution of its solution. Results can be summarized in a radar diagram, an example of which is depicted in the following figure:
Supportability
Functionality 35 30 25 20 15 10 5 0
Reliability Google Apps Existing solution
Usability
Performance
An example of comparative evaluation between Google Apps and an existing solution
[ 226 ]
Chapter 13
Summary
The pilot project goes well beyond designing a simple prototype. Its purpose is more to identity the set of tasks needed to perform the full migration and to mitigate the main technical uncertainties. The greatest risk is defining a scope that is inappropriate. The scope should be adapted to the company's priorities. The classical mistake is to aim for completeness when selecting the features to test. Choosing appropriate services and identifying a representative sample of the user population are the keys to a successful pilot. The final evaluation of the pilot should clearly distinguish between technical issues on one hand and the end-user evaluations of the tools on the other. The pilot phase is a good opportunity to evaluate the amount of support that users really require. When appropriate, ambassadors can replace or complement the traditional helpdesk.
[ 227 ]
Performing the Migration This chapter describes the range of solutions, from Google and its partners, available for uploading data from an existing mail system to Google Apps. Data transfer is here the main issue and most of the chapter is dedicated to this topic. To this day, the most common mail systems are Microsoft Exchange and IBM Lotus Notes. One section is devoted to each. We review in each case the tools available for migration. The last part examines the remaining possibilities in a more generic way.
The steps of the migration
The migration phase is subject to the following prerequisites: •
The user support plan should be ready
•
The pilot project should be completed and consensus should have been reached on its conclusions
•
The gaps between the company's requirements, the features of the Google Apps solution, and the readily available third-party solutions should be known
•
The user training plan should be defined or even completed
•
The reversibility plan should be defined and tested
Once the prerequisites have been validated, the migration proceeds in three steps.
Performing the Migration
User account creation (see Chapter 7) followed by enabling and configuring Google Apps services are the first two steps of the migration. The last is data transfer. User creation App configuration Data Transfer
The three steps of the migration
Data transfer
There is no doubt that the data-transfer step is the most time-consuming part of the migration. Usually, the data to be transferred are the messages, calendar events, and contacts. This asynchronous processing is performed in the Google Cloud using mechanisms similar to batches. Below, we describe in more detail the tools offered by Google for these tasks. We shall stick to the two most common source platforms, namely Microsoft Exchange and IBM Lotus Notes.
Data transfer checklist
Once account creation is complete and the global configuration of the Apps is finished, the data transfer remains. It can be roughly characterized along three axes, which we will look at now. The choice of data to migrate: •
The mail on a server and the local user archives
•
The user contacts and the enterprise directories
•
The calendars and the events they contain
The platforms to migrate, most of the market being shared between: •
Microsoft Exchange
•
IBM Lotus Notes
[ 230 ]
Chapter 14
The actor who will launch the migration: •
An administrator with access to the mail server
•
Users performing the migration themselves using desktop tools
Microsoft Exchange Environment
The migration of data from Microsoft Exchange to Google Apps can be performed by an administrator or, alternatively, by users themselves. The administrators' tools perform batch processes. Users' tools on the other hand, can only upload data for one user at a time, namely the data of the user actually running the tool. For administrators, the standard tool for mail migration is Google Apps Migration for Microsoft Exchange. It can also be used within the generic method (see Chapter 12). On the user side, the most complete tool remains Google Apps Sync for Microsoft. There are alternative solutions too, such as Google Email Uploader or Mail Fetcher.
Administrator tools
The solution developed by Google that allows migration from Microsoft Exchange to Google Apps is named Google Apps Migration for Microsoft Exchange.
Google Apps Migration for Microsoft® Exchange
[ 231 ]
Performing the Migration
Microsoft Exchange Server
R
2 3
Google Apps Migration for Microsoft Exchange Microsoft Outlook
4
Google Apps
1 Accounts list(.csv)
Working principle for Google Apps Migration for Microsoft® Exchange
The tool installs on the desktop of an Exchange administrator and is used as follows: •
Fetch the list of users to migrate by importing a CSV file containing the appropriate information
•
Use the administrator's credentials to access the content of the Exchange server for each of the users defined in the CSV file
•
Fetch the messages, contacts, and calendar events, as requested
•
Convert the messages to the MIME format and upload the message to the associated Google account via HTTP
It is worthy of note that the process handles several accounts simultaneously and that the data is imported into the account from the most recent to the oldest item.
This table shows the compatibility of the mail migration tool in a Microsoft server side environment
[ 232 ]
Chapter 14
This table shows the compatibility of the contact migration tool in a Microsoft server side environment
User tools
There are several applications that allow the migration of messages directly from a Microsoft Exchange mail system to Gmail: •
Google Apps Sync: This is the preferred tool when users are performing the migration. However, it requires Microsoft Outlook version 2003 or later, on which it installs as a plugin. The tool performs the migration of messages, calendar events, and contacts in one shot. It is able to extract data both from the local archive (.pst file) and from the Exchange server. Provided users download the plugin themselves, the workload for the administrator will remain very limited. The solution also offers the possibility to keep Outlook as the mail client and guarantees a thorough synchronization with the Google suite.
Google Apps Sync for Microsoft Outlook
[ 233 ]
Performing the Migration
The tool has a few limitations, though, that you should be aware of: messages with attachments larger than 20 Mb are not taken into account, importing journal entries, and Outlook tasks are, so far, not supported. •
Google Email Uploader is the preferred tool in those cases not covered by Google Apps Sync, especially if the version of Outlook is old or when only another mail client, such as Outlook Express or Mozilla Thunderbird, is used. However, situations where an Exchange mail server is used but Outlook is unavailable on the user desktop are rather uncommon. This tool handles the importation of messages into Google. The tool runs on the user desktop and also handles the contacts and preserves folder structure. Let us note that the tool is Open Source (Apache 2.0 Open-Source Software license).
•
Google Mail Fetcher is a minimal fallback solution that exploits the standard and most basic mail protocol, namely: POP. This protocol is supported by any current mail solution and could thus be useful when Exchange is not used.
This table shows the compatibility of the mail migration tools in a Microsoft desktop environment
This table shows the compatibility of the calendar/event migration tools in a Microsoft desktop environment
[ 234 ]
Chapter 14
This table shows the compatibility of the contact migration tools in a Microsoft desktop environment
Lotus Notes environment
As far as Lotus Notes is concerned, Google provides a tool named Google Apps Migration for Lotus Notes (GAMLN for short). This tool is exclusively intended for administrators and has no equivalent on the user side, as is the case for the Exchange environment. The GAMLN is a native IBM application that installs only on the IBM Lotus Notes Domino server in a Microsoft Windows environment. The main features of GAMLN are: •
Automatic creation of Google Apps accounts.
•
Migration of messages, attachments, and notes. The folder hierarchy is converted into Gmail labels.
•
Migration of contacts and groups.
•
Migration of calendar events.
The migration of everything else in Notes is currently not supported. There are some prerequisites for using this tool: •
The version of IBM Lotus Domino Server should be 6.02 or later
•
The provisioning API should be activated in the Google Apps console
•
The Notes client should be installed and running with administrator privileges [ 235 ]
Performing the Migration
•
The installation of Microsoft Core XML Services 6.0 is required when using ServerXMLHttp to upload data to Google
Installing GAMLN requires the creation of a Lotus Notes database, known as the administration base, entirely dedicated to the migration. The creation of the database starts by using the template provided by Google (gmail-migration.ntf). It contains the set of parameters that need to be defined for the migration. The configuration of a site, associated with the database, is required too. The next step is the definition of the Access Control List (ACL), which defines the administrator rights at the global level, the site administrators, and so on.
The "general" tab in the configuration screen of the administration base
Before launching the migration process, the users should be chosen, whether the migration will take place user by user or by batch. This selection is made directly within the administration database. At this stage, you should define which pieces of data are to be migrated: messages and folders (including junk mail), calendars, contacts, and groups. Archived mail can be included, too. One interesting peculiarity of GAMLN is the possibility to launch the migration by invitation. If this option is chosen, users get a message that invites each of them to launch the migration process by simply clicking on a link in the mail. This has the advantage that each user can freely start the migration at the most appropriate time. For some types of users, this could be useful. This method can also be mixed with the usual method which performs the migration by batch. One other advantage to letting users decide when they want to migrate is that it reduces traffic on the existing mail server.
[ 236 ]
Chapter 14
Sending multiple migration invitations
The general principle is to use a temporary database in which the format conversions take place: conversion to MIME, then to XML, and so on. It might be useful to know that Google provides a GAMLN API for interacting with the Feeder Database. XmL mail
mail Feeder Database
Lotus Notes user
Google Apps contacts and calendars
contacts and calendars
log & stats Administration database
How GAMLN works
Generic tools IMAP method
The IMAP method that we describe here relies on the protocol with the same name: Internet Message Access Protocol (IMAP). It can be used by nearly any mail solution, because IMAP is a widespread standard (for example, Microsoft Exchange, Cyrus Servers, IMPA mail, Dovecot, and so on). This method only allows message fetching. Processes run directly on the server side on the Google platform. The mail is transferred directly from the existing mail to Gmail. [ 237 ]
Performing the Migration
In contrast with the POP protocol that downloads messages on the user's desktop and thus removes them from the server, the IMAP protocol allows synchronizing the content of the hierarchy of messages with the mail client (in our case Gmail). When using IMAP, the messages are not deleted from the server. This method allows an administrator to transfer the content of existing accounts to Google accounts without any intervention from the users. Mechanisms, which we shall describe below, can automate these tasks making this an interesting option when the number of users is large. Remember that the prerequisites for this method are: •
The IMAP feature should be enabled in Google Apps
•
All username and password credentials should be provided to Google
•
Allow Google access to the IMAP port (this can require some firewall tuning)
The fetching of messages using IMAP happens as follows: •
Set up of the connection by an administrator on the Google Apps console. The exact network address of the mail server should be provided to Google, as well as the security options (none, SSL, or STARTTLS), and the folders to be excluded from the transfer (for example, newsgroup data, shared folders, folders containing contacts, or calendar events).
•
Defining the user accounts that should be migrated. Assuming the Google accounts have already been created, this amounts to matching each of them with its corresponding existing account (credentials). This can either be set manually or by using a batch with CSV files when several accounts are involved.
Defining which account to migrate in Google Apps
•
The last step is simply to launch the transfer.
[ 238 ]
Chapter 14
Beware, though, that the massive upload of messages is not misinterpreted as a denial of service attack by the mail server. The risk of blackout can be mitigated by defining pauses in the traffic between Google and the IMAP server.
Alternative solutions
If none of the above solutions we have presented works, there remains the option to use the Google APIs (see Chapter 9), which allow the development of custom migration solutions. However, in most cases, custom development is used to complement the existing solutions, rather than as a substitute. Still another option would be to make use of partner solutions that can be found on the Google Marketplace.
Summary
Google offers a large array of solutions to migrate existing mail systems to its Google Apps solution. The offering is mainly organized around two tools, one for the Microsoft Exchange platform and another for Lotus Notes. For the Microsoft Exchange platform, Google also provides a tool that users can install on their desktop. It can both upload existing data to Gmail and also ensure a thorough synchronization between Outlook and Gmail, meanwhile preserving the possibility for users to keep Outlook as their mail client. The fact that Gmail uses the IMAP protocol, enables fetching messages from any standard mail server. In other, more complicated situations, specific developments using the Google API may be the only solution.
[ 239 ]
Index A access control 30 Access Control List (ACL) 236 ACS (Assertion Consumer Service) 148 advanced elements administration APIs 137 authentication, managing 136 Google Analytics, enabling 137 managing 136, 137 advanced strategy 206 agentId parameter 166 Android about 179 advantages 180, 181 and mobile devices 179 features 180 announcements 93 anti-spam 54, 55 anti-spam filters about 106 adjusting 112 individual user accounts 107 user organizations 107 antivirus 54 antivirus filters about 106 individual user accounts 106 individual user organizations 106 API, for Application Management calendar data API 161 contacts data API 161 documents list data API 162 sites data API 162 spreadsheets data API 162
API, for Domain Management about 162 domain shared contacts API 162 email migration API 162 email settings API 162 provisioning API 163 reporting API 163 user profiles API 163 archives managing 111 archiving tools features 98 asset classification and control 29 asynchronous tasks 120 attachment filters 109 attachments Google documnets, using as 76 audio, Google Talk using 66 authentication managing 136 Authentication Server (AS) 153 auto-completion feature, Gmail 50
B Blacklists defining 102
C calendar address, URL 64 calendar data API 161 Calendar Gadgets 168 centralized architectures 17 charts, Google Spreadsheets 80
Chrome OS and user desktop 174, 175 Chrome web browser 175 Chrome OS operating system about 178 graphical interface 179 performance 179 Chrome web browser features 177, 178 graphical interface 175, 176 performance 176 reliability 176 security 176 client-server architecture 17 cloud about 12, 13 impact, on IS 20 cloud computing and Application Service Provider, differences 13, 14 and Google 12, 13 cash requirements, reducing 23 costs and investements, reducing 23 cost visibility, improving 23 economic impact 22 hosting modes 14, 15 collaboration on document 86 real-time collaboration, with spreadsheets 86, 87 real-time collaboration, with text documents 87 company profile appropriate population. targeting 198, 199 geographic dispersion 198 identifying 197 organization, size 197, 198 contact, Google Talk blocking 66 contact management, Gmail 53, 54 contacts 53 contacts data API 161 content filters 107-109 Convertigo about 183 advantages 185 enterprise mashups 183, 184
solutions 184 URL 186 use cases, example 184 cookies 34 Cordys about 190 use cases 191 CSV file, Google Apps uploading 133
D data 23-36 data privacy about 32 connection data 34 cookies 34 geographic location 34 personal information, usage 33 principles 32 technical means 34 datastore, Google App Engine for Business (GAE) 121 data transfer about 230 checklist 230, 231 data validation, Google Spreadsheets 79 deployment environment, Google App Engine for Business (GAE) about 118 Java environment 119, 120 sandbox 118, 119 Discovery Service (DS) 147 document, sharing about 83 as web page 85 link used 85 with authenticated users 84 document history, Google Docs accessing 76 documents, Google Docs searching for 75 documents list data API 162 DocVerse 90, 91 Do It Yourself strategy 205 domain ownership confirming 129
[ 242 ]
domain settings account related settings 136 adjusting 136 domain names 136 general settings 136 domain shared contacts API 162 drawings, Google Spreadsheets 80
E education edition, Google Apps 127 elementary phases, migration strategy about 202 advanced integration, performing 203, 204 pilot, designing 202 preliminary study, performing 202 rollback plan, setting up 203 users, training 202 user support, setting up 203 email migration API 162 email settings API 162 Enterprise Mashups, Convertigo 183, 184 events, Google Calendar creating 58, 59
F fat client access Gmail 70, 71 Google Calendar 71 File Cabinet Page 93 filters about 52, 53 anti-spam filters 106 attachment filters 109 content filters 107 for Gmail, managing 105 flash strategy 204 formatting, Gmail 49 forms, Google Spreadsheets creating 81, 82 formulas, Google Spreadsheets 78
G gadgets about 94 inserting, in portal 167
gadgets, Google Spreadsheets 80 GAMLN about 235 features 235 installing 236 prerequisites 235 Gmail about 45, 46, 137 accessing, fat client used 70, 71 accessing, ways 68 anti-spam 54, 55 antivirus 54, 55 auto-completion feature 50 constant improvements 46, 47 contact management 53, 54 filters 52, 53 IMAP and POP access 56, 57 import-export features 50 labels 50, 51 mail servers 47 messages, searching for 52 mobile access 68 offline mode feature 72 reliability level 48 search- and conversation-oriented GUI 48, 49 spell-checking and formatting 49 state-of-the-art security tools 47 translation tools 55, 56 Gmail Gadgets 168 Google about 11 and cloud computing 12, 13 connection data 34 cookies 34 data 34, 36 data security 25 figures 11 geographic location 34 services 34, 36 Google's offering, Information System 174 Google Analytics enabling 137 Google App Engine for Business (GAE) about 116, 117 custom code, running 166, 167 datastore 121
[ 243 ]
deployment environment 118 examples, of sites 121 quotas 121 services 120 Google App Engine for Business (GAE), services image manipulation service 120 mail service 120 memcache service 120 URL fetch service 120 Google Apps accessing, from third party application 160, 161 additional services 140 administration console, settings 150, 151 and OpenID 156, 157, 158 authentication 151, 152 directory Synce tool 135 education edition 127 functional requirements 200 gadgets, inserting in portal 167 Gmail 137 Google Calendar 138 Google Docs 138 Google sites 139 Google Sync 139 Google Talk 138 Google video 139 integration modes 160 legal 37 non-functional requirements 201 Postini services 139 premier edition 127 provisioning API 135 provisioning toolkit 135 SAML binding 151 SAML profile, specifying 151 Shibboleth configuration 151 SP binding 151 standard edition 127 steps, for registering 128 subscribing to 127 users, adding to 219 user-managed groups, activation 135, 136 user accounts, creating 132 workflow 148
Google Apps, integrating with Enterprise SSO about 153 Kerberos protocol 153, 154 Shibboleth, setting up for Kerberos 154, 155 Google Apps, registering steps about 128 domain ownership, confirming 129 MX-records, changing to activate Gmail 130 Postini services, activating 131 user accounts, managing 130 Google Apps account domain name, selecting 218, 219 dual-delivery, via Enterprise Mail Server 220 dual-delivery, via Google 221 Gmail, enhancing 222 Google Apps services, configuring 220 Google Apps services, enabling 220 Google Calendar, enhancing 222 signing up for 218, 219 users, adding to Google Apps 219 version, selecting 219 Google Apps Marketplace about 113, 114 application, installing 115 Google Apps Migration for Lotus Notes. See GAMLN Google Apps services configuring 220 dual-delivery, via Enterprise Mail Server 220 dual-delivery, via Google 221 editions 43 enabling 220 Gmail, enhancing 222 Google Calendar, enhancing 222 Google Apps Sync 233. 234 Google Calendar, publishing about 63 calendar address, URL 64 formats 64 HTML format 64 ICAL format 64 private address, URL 64
[ 244 ]
URL, types 64 XML format 64 Google Calendar accessing, fat client used 71 accessing, ways 68 calendars, creating 58, 59 calendars, sharing 60 domain, sharing within 61, 62 events, creating 58, 59 import/export features 58 mobile access 68 multi-calendar-oriented GUI 57 notifications, defining 59, 60 offline mode feature 72 predefined calendars 58 privacy levels, setting 60 public sharing, sharing within 61, 62 publication, formats 64 publishing 63 reminders, defining 59, 60 resource planning 62, 63 specific users, sharing with 60 Google corporate security policies 27 Google Docs about 138 document, collaborating on 86 document history, accessing 76 exporting 88 Google Drawing 83 Google Presentations 82 Google Spreadsheets 77 importing 88 offline mode 90 presentations 89 publishing, as web page 85 Real-time collaboration, with spreadsheets 86, 87 Real-time collaboration, with text documents 87 searching for 75 sharing 83, 84 sharing, link used 85 sharing, with authenticated users 84, 85 spreadsheets 89 spreadsheets, protecting 87, 88 templates, using 88 text documents 89
text documents, editing 74, 75 using, as attachments 76 versus conventional office suite 73, 74 Google Drawing 83 Google Email Uploader 234 Google Mail Fetcher 234 Google objects 94 Google Presentations about 82 creating 82 editing 82 images, inserting 82 making 82 organizing 82 videos, inserting 82 Google Sites about 91, 139 access rights, defining for collaboration 95 objects, categories 94 pages, creating 93, 94 Google Spreadsheets about 77 charts 80 creating 77 data validation 79 display rules 78, 79 drawings 80 editing 77 formats 78, 79 forms, creating 81 formulas 78 gadgets 80 tabs 77 Google storage 168, 169 Google Sync 139 Google Talk about 138 audio, using 66 contact, blocking 66 integrating, with Gmail 65 privacy 67 standalone application 67 translation 66, 67 video, using 66 Google Video 95, 96, 139 graphical interface, Chrome OS Operating System 178
[ 245 ]
graphical interface, Chrome web browser 175, 176 groups, Google Apps creating 133, 134
H hosting modes hardware 15 middleware 15 operational resources 15 software 15 HTTP protocol 161 HTML format 64
I IaaS 11, 15 ICAL format 64 Identify Provider (IdP) 147 IdP-initiated Web SSO 145 IMAP and POP access, Gmail 56, 57 IMAP method about 237 messages, fetching 238 prerequisites 238 import/export features Google Calendar 58 Gmail 50 in-house hosting 15 Information Systems. See IS Infrastructure as a Service. See IaaS Internet2 146 Internet Server Application Programming Interface. See ISAPI IS accessing 171 cloud impact 20 Google's offering 174 in 2000s 20 in 2010s 21, 22 layers 20 mobile devices 172, 173 user desktop 172 ISAPI 147
J JAAS Login Module 154 Java Architecture for XML Binding (JAXB) 119 Java Beans Activation Framework (JAF) 119 Java Data Objects (JDO 2.3) 119 Java Mail 119 Java Persistence API (JPA 1.0) 119 Java Server Faces (JSF 1.1 et 2.0) 119 Java Server Pages (JSP et JSTL) 119 Java Servlet API 2.4 119 JVM (Java Virtual Machine) 116
K Kerberos protocol about 153, 154 Shibboleth, setting up for 154 Key Distribution Center (KDC) 153
L labels, Gmail 50, 51 LAMP 147 light strategy 205 List Page 93 Lotus Notes Environment. See GAMLN
M mail service 120 mail system 199, 200 makeRequest API 163 MDSSO 143 memcache service 120 Message Center about 99, 100 early detection quarantine 101 personal archive 101 quarantine, for infected messages 100, 101 quarantine, for spam 100 Microsoft Exchange Environment about 231 administrator tools 231, 232 user tools 233-235
[ 246 ]
migration prerequisites 229 migration strategy advanced strategy 206 Do It Yourself strategy 205 flash strategy 204 for Organization of Type 1 (OT1) 206 for Organization of Type 2 (OT2) 206, 207 for Organization of Type 3 (OT3) 207 for Organization of Type 4 (OT4) 207 for Organization of Type 5 (OT5) 207, 208 for Organization of Type 6 (OT6) 208 for Organization of Type 7 (OT7) 208 for Organization of Type 8 (OT8) 209 functional requirements 200 light strategy 205 non-functional requirements 201 performing 204 phases 201 projects 201 requirements 200 standard strategy 205 types 204 mobile access Gmail 68, 69 Google Calendar 69, 70 mobile devices, Information System 172, 173 multi-calendar-oriented GUI, Google Calendar 57 multi-layer security strategy access control 30 asset classification and control 29 disaster recovery 31 environmental security 29, 30 Google corporate security policies 27 operational security 30 organizational security 28 personnel security 29 physical security 29, 30 regulatory compliance 31, 32 systems development and maintenance 31 Multiple-Domain web Single Sign-on. See MDSSO MX-records activation 130
N non-Google objects 94 notifications, Google Calendar defining 59, 60
O objects categories 94 gadgets 94 Google objects 94 non-Google objects 94 OffiSync 114 offline mode feature Gmail 72 Google Calendar 72 Open Authentication (OATH) 152 OpenID about 155, 156 and Google Apps 156-158 operational security 30 organizational security 28 Organization of Type 1 (OT1) migration strategy for 206 Organization of Type 2 (OT2) migration strategy for 206, 207 Organization of Type 3 (OT3) migration strategy for 207 Organization of Type 4 (OT4) migration strategy for 207 Organization of Type 5 (OT5) migration strategy for 207, 208 Organization of Type 6 (OT6) migration strategy for 208 Organization of Type 7 (OT7) migration strategy for 208 Organization of Type 8 (OT8) migration strategy for 209
P PaaS 11, 15, 166 pages Announcements 93 File Cabinet Page 93 List Page 93
[ 247 ]
Start Page 93 types 93 Web Page 93 personnel security 29 physical and environmental security 29 30 pilot project about 211 implementing 218 issues 211 results, evaluating 225, 226 scheduling 212 Platform as a Service. See PaaS Postini administration features 103 anti-spam filter, adjusting 112 anti-spam filters 106 anti-spam filters, content filters 107-109 anti-spam filters, user organizations 107 antivirus filters, individual user accounts 106 antivirus filters, user organizations 106 antivus filters 106 archives, managing 111 attachment filters 109 default authorizations 104 filters, managing for Gmail 105 message, recovering from quarantine 112 notifications, defining 110 organizations, creating 103, 104 security settings, optimizing 112 user authorizations, defining 104 users, creating 103, 104 Postini services about 139 activation 131 premier edition, Google Apps 127 privacy, Google Talk blocking 67 private address, URL 64 private cloud 19, 20 provisioning API 163 public cloud 19, 20
Q quarantine early detection quarantine 101
for infected messages 100, 101 quotas, Google App Engine for Business (GAE) 121
R reminders, Google Calendar defining 59, 60 reporting API 163 resource planning, Google Calendar 62, 63 RunMyProcess about 114, 187 application gadget 189 SaaS synchronization 188 SaaS workflow 188 use cases 188
S SaaS about 11, 16 and data security 25, 26 and Software Architectures 16 centralized architectures 17 client-server architecture 17 opportunities 26 standalone architectures 18, 19 web architectures 18 SAML assertion 144 binding 145 concepts 143-145 IdP-initiated Web SSO 145, 146 implementation example 146, 147 profile 145 protocol 144 SP-initiated Web SSO 146 SAML assertion 144 SAML binding 145 SAML profile 145 SAML protocol 144 scope application, selecting 213 archives, transfering 216 authentication mechanism 216 channels, accessing 216 defining 212 extending 215 [ 248 ]
external mailing lists, managing 215 pilot users, selecting 214 reversibility mechanisms 218 rollback mechanisms 218 TCO 217 user-identity lifecycle 215 SDC about 163 activating 165 call, workflow 163, 165 configuration 165 local configuration 166 setting up 165 search- and conversation-oriented GUI, Gmail 48, 49 Secure Data Connector. See SDC Service Provider (SP) 147 services 24-36 Shared contacts 114 Shibboleth about 146 Discovery Service (DS) 147 Identify Provider (IdP) 147 Service Provider (SP) 147 Shibboleth, configuration SAML profile, specifying 151 SP and SML binding 151 simply SSO. See MDSSO Single Sign On. See SSO sites data API 162 Sites Gadgets 168 Smartsheet 114 Software as a Service. See SaaS spell-checking, Gmail 49 SP-initiated Web SSO 146 Spanning Sync 114 spreadsheets real-time collaboration with 86, 87 Spreadsheets API 168 spreadsheets data API 162 SSO issues 141, 142 standalone architectures 18, 19 standard edition, Google Apps 127 standard strategy 205 Start Page 93 systems development and maintenance 31
T tabs, Google Spreadsheets 77 TCO 217 templates using 88 text documents real-time collaboration with 87 text documents, Google Docs creating 74, 75 editing 74, 75 threshold defining, for anti-spam filter 102 Ticket Granting Server (TGS) 153 translation tools Gmail 55, 56 Google Talk 66, 67
U urlFetch API 163 URL Fetch Service 120 user accounts managing 103 user accounts, Google Apps creating, manually 132 user desktop and Chrome OS 174, 175 user desktop, Information System 172 user profiles API 163
V video, Google Talk using 66
W Wave Gadgets 168 web architectures 18 Web Page 93 Whitelists defining 102 WIMP 147
X XML format 64 [ 249 ]
Thank you for buying
Google Apps: Mastering Integration and Customization
About Packt Publishing
Packt, pronounced 'packed', published its first book "Mastering phpMyAdmin for Effective MySQL Management" in April 2004 and subsequently continued to specialize in publishing highly focused books on specific technologies and solutions. Our books and publications share the experiences of your fellow IT professionals in adapting and customizing today's systems, applications, and frameworks. Our solution based books give you the knowledge and power to customize the software and technologies you're using to get the job done. Packt books are more specific and less general than the IT books you have seen in the past. Our unique business model allows us to bring you more focused information, giving you more of what you need to know, and less of what you don't. Packt is a modern, yet unique publishing company, which focuses on producing quality, cutting-edge books for communities of developers, administrators, and newbies alike. For more information, please visit our website: www.packtpub.com.
Writing for Packt
We welcome all inquiries from people who are interested in authoring. Book proposals should be sent to
[email protected]. If your book idea is still at an early stage and you would like to discuss it first before writing a formal book proposal, contact us; one of our commissioning editors will get in touch with you. We're not just looking for published authors; if you have strong technical skills but no writing experience, our experienced editors can help you develop a writing career, or simply get some additional reward for your expertise.
Microsoft Azure: Enterprise Application Development ISBN: 978-1-849680-98-1
Paperback: 248 pages
Straight talking advice on how to design and build enterprise applications for the cloud using Microsoft Azure 1.
Build scalable enterprise applications using Microsoft Azure
2.
The perfect fast-paced case study for developers and architects wanting to enhance core business processes
3.
Packed with examples to illustrate concepts
Amazon Web Services: Migrating your .NET Enterprise Application ISBN: 978-1-849681-94-0
Paperback: 336 pages
Evaluate your Cloud requirements and successfully migrate your .NET Enterprise Application to the Amazon Web Services Platform 1.
Get to grips with Amazon Web Services from a Microsoft Enterprise .NET viewpoint
2.
Fully understand all of the AWS products including EC2, EBS, and S3
3.
Quickly set up your account and manage application security
4.
Learn through an easy-to-follow sample application with step-by-step instructions
Please check www.PacktPub.com for information on our titles
