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
<99.9% but ≥ 99.0%
3 days
<99.0% but ≥ 95.0%
7 days
< 95%
15 days
General information A search- and conversation-oriented GUI
The GUI of Gmail is actually both search-oriented and conversation-oriented. On the left of the screen is a set of links that allows you to select various types of messages such as: starred messages, sent messages, drafts, and so on. At the top of the screen you find a particularly powerful search tool, especially when the advanced version is used. We shall come back to this shortly.
Gmail has a search- and conversation-oriented GUI
� ���� SLA �� = ����������������������� Service Level Agreement
[ 48 ]
Chapter 3
Messages are actually grouped into conversations between users. This is quite a useful feature, but some users who not familiar with this type of classification might first need to get acquainted with it. For users who want to keep a standard "unthreaded" view in their Gmail UI, this was made possible by Google during 2010: http://googleappsupdates.blogspot.com/2010/10/unthreadedconversation-view-in-gmail.html
FMail is organized in conversation which can either be expanded or collapsed.
Spell-checking and formatting
Just as any other text-processing system, Gmail offers an online spell checker. For the moment, spell checking does not occur in real time but must be explicitly requested. Even though the tool is rather rudimentary at the moment, it honestly does the job you'd expect.
The formatting toolbar and the spell checker in action
Without pretending to be a substitute for a word processor like Microsoft Word or Apple Pages or even like Google Docs from the Google Apps suite (see Chapter 4, Collaboration Tools), Gmail offers some rudimentary formatting as shown in the previous screenshot.
[ 49 ]
Communication Tools
The auto-completion feature
Auto-completion is particularly useful for entering a list of message recipients:
Auto-completion while entering a recipient in Gmail
This feature is, in particular, available in all the features of Google Apps that are based on Gmail's address book.
Import-export features
A list of contacts can be easily imported into the Gmail address book using a CSV file exported from applications such as Outlook, Outlook Express, Yahoo Mail, Hotmail, Eudora, Orkut, and others. Each import is limited to 3000 users. Conversely, it is possible to export the Gmail address book in the following formats: Google CVS, Outlook CVS, or vCard from Apple. As far as importing the messages themselves into Gmail, the actual procedure will depend a great deal on the mail platform from which you are starting. Provided you have registered for a Google Apps account, there is Google Apps Sync for MS Outlook, which is a free tool that allows you to import at once a whole set of messages retrieved from either a .pst file or from an Exchange profile. These migration issues will be discussed in more detail in Part 4 of this book.
The main features Labels
One of the most useful and innovative features in Gmail is probably the use of labels as a mechanism for message classification. They are actually meant to replace the more conventional use of a hierarchy of folders.
[ 50 ]
Chapter 3
Labels are just tags that are associated to a set of messages.
An example of using labels to classify messages in Gmail. Several labels can be associated to a single message.
Perhaps the main advantage of using labels instead of folders is that several labels can be associated to a single message whereas obviously each message can only be contained in a single folder. A few carefully chosen labels, which typically correspond to habitual tasks, can create a very efficient classification scheme. This way, searching is made particularly fast and easy. Gmail provides a number of predefined labels ("Inbox", "Starred"…), a list that each user can extend with his or own labels. At first, using labels might be puzzling for those users who are accustomed to putting things in folders, then subfolders, and so on. But after a short period of acquaintance, labels will prove much more practical than folders. Here are a few good practices that we recommend: •
Use just a few labels and combine them to classify messages.
•
Create temporary labels for tasks related to temporary projects.
•
To avoid an uncontrolled accumulation of labels, you should delete them when they become obsolete. The message should then be classified with generic label replacing the former one.
•
Systematically use search tools to find old messages (see the following).
[ 51 ]
Communication Tools
Searching for messages
Gmail search tools are particularly effective when used in conjunction with the labels we just presented. There are essentially three ways to perform searches. Not surprisingly, the first one uses a number of search criteria:
Entering search criteria in Gmail
The second search method is best suited to performing simple searches for a string within any part of the messages (body, subject, address):
Searching message for a particular string within the body or the subject of the messages
Finally, you can use a combination of keywords (such as "has:attachement", "is: unread", and so on to perform more sophisticated searches:
Searching for messages, which contain two specific labels and which have been read
It is worth mentioning that searches include the contents of chat messages as well.
Filters
Defining a set of filters can help to automate a number of recurring tasks such as: sorting, archiving, labeling, deletion, or forwarding. Filters are defined in two steps. First, we have a set of filtering criteria:
[ 52 ]
Chapter 3
Entering filtering criteria.
Secondly, there are the actions to take on filtered messages:
Defining which action should be taken on filtered messages
Contact management
Contact management is an integral part of Gmail. These contacts can be reused in many other Google Apps applications and services, namely for document sharing and collaboration (see, for instance, Chapter 4, Collaboration Tools on Google Docs and Google Sites) and to send invitations through Google Calendar.
Contact and group management within Gmail
[ 53 ]
Communication Tools
There are actually three predefined contact groups: •
All contacts: just as it says!
•
My contacts: a list of contacts that you choose and to which you attach special importance.
•
Frequently used: the 20 contacts you use most often.
Groups can be user-defined. In a way, they are quite similar to the labels we discussed above. The same user may simultaneously belong to several groups. This data can be synchronized online with the address books of most smartphones (see Chapter 5, Managing a Google Apps Domain).
Anti-spam and Antivirus
From a user perspective, the operation of anti-spam and anti-virus tools is completely transparent. The user needs to do nothing! It is the administrator who is entirely in charge of configuring Postini security tools through the so-called Content Manager (see Chapter 5). One of the administrator's tasks is to define filter settings that enforce company regulations regarding the content of outgoing or incoming mail messages as well as the type of mail attachments. Postini anti-virus thus adds one security layer to the basic security services already provided by Gmail. Any message that is deemed suspicious by one of these filters will be automatically routed to the quarantine. After examination, by the user or the administrator, it may be routed to the inbox or deleted permanently. Quarantine
Blocked message
Internet
Message security anti-spam filter anti-virus filter regulatory filter
Gmail
Copied message
Searching for messages Message archives Private archives
Schematic workings of the anti-spam, anti-virus, and content filters for incoming mail. Rules should be set at an enterprise level to block illegitimate mail using criteria such as the source of the mail, the nature of its attachments, or the occurrence of some keywords in its content. A similar pattern applies to outgoing mail and to messaging within the company. [ 54 ]
Chapter 3
An archiving service, named the Message Discovery Service is available as an extension to the basic security service. It can provide an online archive for a preset period ranging from 1 to 10 years and even for several decades without any limit on storage space! This can prove particularly useful for legal archiving, for human resources, and so on. Once it has been archived, a message can't be modified anymore and therefore possesses a legal value. A global, centralized archive maintains a copy of all messages of all users of a Google Apps domain. Moreover, users have individual access to their own personal archive provided the administrator has granted them the appropriate right. Access is via a web application called the "Message Center".
The Message Center is a web application that allows users to access their personal archive and to view their quarantine
Lost messages can thus be recovered and suspect messages can be analyzed safely.
Translation tools
The goal of Google, in the long run, is to remove any language barrier on the Web. Among the concrete steps taken in this direction, let's mention an automatic translation tool that has been available in Gmail Labs since May, 2009.
Enabling or disabling the automatic translation service in Gmail Labs
[ 55 ]
Communication Tools
It is therefore possible to use Gmail to have a conversation where each writer uses his or her own mother tongue. Considering the present quality of translation, this vision remains somewhat theoretical but the feature may still be quite useful and the accuracy of translation is only improving with time.
The translation tool integrated in Gmail.
IMAP and POP access
Let's recall that the now-aging POP protocol can fetch mail from a server to a mail client. This protocol thus operates in a unidirectional mode. Once it has been transferred from the server to the client, a message will generally be deleted from that server. The IMAP protocol is more complex than POP but allows a two-way synchronization between a mail client and a server. Moreover, it does not imply the deletion of the original message from the server. Thus, it is clearly more appropriate for wireless, multi-channel messaging. Today, it is the de facto standard for mobile access. Moving a message from one folder to another or deleting a message on the local client will automatically be reflected on the Gmail web client and vice versa. It is important to be aware though that, due to the nature of the IMAP protocol, a message with multiple labels will be downloaded as many times as there are different labels. Generally, this is not an issue, given the small size of most messages and provided you take care not to download large attachments redundantly. Gmail supports both POP and IMAP protocols, but whenever possible, an IMAP access should be preferred. It is the domain administrator's responsibility to enable POP and/or IMAP access. The user will still need to configure his mail client properly.
[ 56 ]
Chapter 3
The administrator can enable or disable POP and IMAP access for Gmail. Each user should then specify which access he wants
Google Calendar in detail General information Multi-calendar-oriented GUI
Google Calendar can simultaneously display several calendars. Although the interface is rather complex, it is nearly as responsive as the interface of a traditional heavy client; just one click instantaneously displays or hides the agenda calendar. Usual views, per day, per week, or per month are available as well as an agenda view.
The Google Calendar interface shows several calendars simultaneously [ 57 ]
Communication Tools
Predefined calendars
Google Calendar offers a long list of predefined calendars, ranging from holidays in many countries to sporting events and the phases of the moon.
Google Calendar offers a large variety of predefined calendars
Import/export features
Google Calendar can export a specific calendar or a whole collection of them. The iCalendar standard is used because it is recognized by most planning tools like Microsoft Outlook, Calendar, Apple iCal, Yahoo! Events and so on. Those same tools will therefore be able to properly interpret the invitations sent by Google Calendar (and vice versa). Files using this format are recognized by their .ics extension. A set of calendars will be exported as a ZIP file containing several .ics files. Imports, in turn, can use either iCalendar or CSV files. In the latter case, though the system may replace one repeating event with a series of events at the corresponding dates.
The main features Creating calendars and events
Google Calendar allows the creation of an arbitrary number of calendars. Within any given calendar, a period of time is usually called an event. Each of those events, in turn, is characterized by three types of information: the time slot, the guest list, and the various options for setting reminders, specifying the availability, and the privacy settings.
[ 58 ]
Chapter 3
Entering an event in Google Calendar: the time slot, the guest list, and the various options for setting reminders, specifying the availability and the privacy settings
Guests will each automatically receive an invitation as a message in Gmail, to which they may then respond by indicating whether they will attend the event or not.
After an event has been entered in Google Calendar, the system will automatically send an email to every guest, who can then indicate whether they intend to attend the event or not by clicking a link in the mail
Defining reminders and notifications
Each event can be configured with a list of reminders that will show up between 4 weeks and just 1 minute before the event occurs. Three different channels are available for these notifications: email, a popup that appears in the browser window, and SMS (which is free!):
Definition of a list of reminders for a calendar event, by mail, using a popup or using a SMS [ 59 ]
Communication Tools
Default values can be set separately for each calendar. Notifications in case of a change of an invitation status (received or sent) can be defined as well, as the following figure shows:
Each calendar has its own configuration for event reminders and for status change notifications when an invitation has either been received or sent
Sharing calendars and setting privacy levels
Each calendar can be shared, either with users chosen from the Gmail contact list, or with all users from the Google Apps domain. A calendar can also be made public so that anyone in possession of its URL can view it.
Sharing with specific users
Four levels of visibility can be set for calendars that are shared with specific users: •
Allow updating and managing the calendar
•
Allow updating the calendar
•
Allow viewing the details of any event
•
Allow viewing the availability on any event
[ 60 ]
Chapter 3
Sharing within the domain and public sharing
By contrast, only two levels of visibility are available in case of public sharing or when sharing with all users in the domain, namely: See all event details or See only free/busy:
Each calendar can be shared either with specific people from the Gmail contact list or with all people in the Google Apps domain. It can also be made completely public.
Each event can define in turn its own privacy settings. There are three such levels: Default, Private, or Public:
There are three possible privacy levels for an event in Google Calendar
Not surprisingly, Default confidentiality implies that the privacy level in the calendar will take precedence. The two other options: Private or Public on the other hand, will respectively strengthen or weaken the visibility defined in the calendar. Following is a table that summarizes exactly what a user can see as a function of the privacy settings defined both on the event and on the calendar that contains it.
[ 61 ]
Communication Tools
The header line indicates the privacy level that was defined on an event. The first column on the left indicates the privacy level that was defined for the user(s) on the calendar that contains the event. The body of the table indicates what the user(s) can see. Event with default visibility
Event with private Event with public visibility visibility
Allow updating and managing the calendar
The details of the event are visible
The details of event are visible
The details of event are visible
Allow updating the calendar
The details of the event are visible
The details of event are visible
The details of event are visible
Allow viewing the details of the events in the calendar
The details of the event are visible
Only free/busy information is visible
The details of event are visible
Allow viewing the free/busy information
Only free/busy information is visible
Only free/busy information is visible
The details of event are visible
To conclude this paragraph, let us mention that Google Calendar proposes a delegation mechanism: managers can thus delegate the management of their agenda to their assistant.
Resource planning
Google Calendar lets you book resources such as rooms or equipment. All that is needed is to associate a calendar to each resource that can be booked. The only distinction with a regular calendar is that the option Auto-accept invitations that do not conflict should be checked:
Defining a resource calendar implies checking the option "Auto-accept invitations that do not conflict", while creating the agenda. This will cause any invitation to be automatically accepted when the time slot is available.
[ 62 ]
Chapter 3
Thus, each reservation will be accepted provided the time slot is available. Once the calendar has been created, all people who may reserve the resource should be invited either one by one or as a group. Users will then receive a mail notifying them that they have access to a new calendar and will therefore now be able to make reservations. A user who wants to make a reservation for a resource should now simply create an event in the corresponding agenda for the given time slot. Before validating the reservation, the user can check the availability of the resource and, where relevant, invite people for a meeting.
Checking the availability of people and resources in Google Calendar before creating an event or reserving a resource
Publishing a calendar
A calendar can be published to be accessible in read-only mode within third-party applications. There are three different formats and two kinds of URLs for this purpose.
There are two kinds of URLs and three formats to grant read-only access to a calendar
[ 63 ]
Communication Tools
Three formats for publication •
The HTML format: The URL that is provided can be used to display the calendar in read-only mode in a browser. As we mentioned above in the section on calendar sharing, it is possible either to restrict the publication to availability information only or to publish all the details of each event.
•
The XML format: In this case, the URL can be used to subscribe to the event stream from the calendar as an RSS feed and display it in Google Reader, for instance.
•
The ICAL format: This allows using the calendar in any software that understands the iCalendar format such as Apple's iCal.
Two kinds of URL •
The calendar address. This type of URL, which exists for the three above-mentioned formats, is used for sharing a calendar with other users. Sharing can be with everyone on the Web, which means the calendar is made public, or only with selected users as we described earlier.
•
The private address. This is a strictly confidential URL and again it exists for the three above-mentioned formats. It should be used only by the owner of the calendar. This type of address can be used for instance in conjunction with widgets that can integrate one or more Google Calendars in some popular portals, like Netvibes or iGoogle:
Google Calendar widgets. For Netvibes on the left and for iGoogle on the right.
Finally, let us mention that calendars can be easily integrated within a Google Docs page (see Chapter 4, Collaboration Tools) or in a blog.
[ 64 ]
Chapter 3
Instant messaging with Google Talk Integration with Gmail
Instant messaging, named Google Talk, is available directly from within Gmail. Both applications share the same contacts. The following icons indicate the status of each contact:
From left to right, the contact is: available to chat, available to chat in audio and video, is online but busy, is online but absent for the moment, offline right now
Behind the scenes, Gmail automatically determines which user you contact most often, and then incorporates those into the Google Talk list. It is possible, though, to check an option in Google Talk so that the system explicitly asks whether or not the contact should be added to the chat list. Google Talk offers group chat. Each user can invite several other users in a chat:
On the left, the integrated Gtalk widget with presence indicators. On the right, an example of a group chat.
With Google Talk, you can chat with users that belong to other domains and therefore to other companies. This feature will prove particularly useful for communications with partners, customers, and suppliers. [ 65 ]
Communication Tools
Audio and video
To use video and audio chat, it is necessary to first install the Google Gears plugin. Chrome OS users are exempt from this prerequisite because the latest versions (4.0) natively include these features. With the forthcoming advent of HTML 5, it is likely that this plugin will no longer be necessary.
Video chat within the browser through Google Talk.
Blocking a contact
To help discretely get rid of intruders and other boring people, Google Talk proposes to "block" them. Once a contact has been blocked he or she won't be able to communicate with you anymore and you won't see the contact's name in your list either. Should you return to better feelings later, you can always unblock the contact and then start new conversations. Note that Google Talk now offers an "invisible" mode that allows masking your presence while still allowing you to see your contacts' online status.
Instant translation
Instant translation is available on Google Talk. Simply invite a virtual contact (technically called a "bot") that will act as a translator in the conversation. Once it has been invited, it will always be present in the following chats:
[ 66 ]
Chapter 3
Translation in action within Google Talk instant messaging. The English to French translation uses the "bot" named
[email protected].
Privacy
A chat on Google Talk is often regarded on the same footing as an informal and oral communication, which we do not necessarily want to keep track of. For this reason, it is possible to select an option that prevents the recording of instant messages.
Standalone application
Most multi-protocol instant messaging clients (Adium, Pidgin, Miranda,…) can connect to Google Talk. The Google Talk Gadget that only exists for the Windows platform is of interest for two primary reasons: •
It can transfer large files between two users with no practically no size limitation, as opposed to mail attachments (< 20 MB)
•
It also sends a real time notification when a new a mail message arrives in the Gmail inbox
The Google Talk Gadget, which is available for Windows only. It can transfer large files between two users. [ 67 ]
Communication Tools
Other ways to access Gmail and Google Calendar Mobile access
Before turning more specifically to Gmail and Google Calendar features on smartphones, let us note that there is an online synchronization service, named Google Sync, that can help synchronize Gmail messages, Google Calendar events, and contact information with the corresponding data on a smartphone. Most importantly, it does not require any complex configuration from the user. There is also a push service, which allows receiving mail without having to explicitly check for new messages. The detail of each feature will of course depend on the smartphone. As a general rule, hardware that runs Android OS will offer a slightly higher degree of integration with the Google Apps than the other. In any case, the protocol used is Microsoft® Exchange ActiveSync®. For enterprise use of smartphones, Google has integrated new administration features, among which the most important are certainly the following: •
Remote reset and formatting of the phone, in case of theft
•
The ability to shut down unused services after a period of inactivity
•
Requirement of a password of minimal length on each phone
See: http://googleappsupdates.blogspot.com/2010/10/new-features-tomanage-android-mobile.html
Gmail
Gmail is obviously available on all current mobile terminals (Android, BlackBerry, iPhone, Nokia/Symbian, webOS, Windows Mobile, iPad…). They all use the IMAP protocol to access Gmail. Each phone has its own IMAP settings that will allow simultaneous synchronization of mail, calendars, and contacts. There are two ways to access Gmail on a mobile phone: either using the mobile web app for Gmail, or using a dedicated mail client on the phone:
[ 68 ]
Chapter 3
From left to right: the dedicated application for Gmail on the Nexus S from Google, the Mail client on the iPhone, and the mobile web app for Gmail
It is generally considered that the dedicated applications provide a better user experience than the mobile web application. You should keep in mind though, the limitation of the IMAP protocol we referred to earlier, namely the duplication of the messages that have several labels. All these applications are of course free. The Gmail mobile web application has an offline mode, just like the regular Gmail application. This feature allows reading and writing mail in the absence of network coverage.
Google Calendar
In a similar way, Google Calendar can be accessed on a mobile phone either through a dedicated application or by connecting to the mobile web app.
From left to right, the calendar on the Nexus One, on the iPhone, and the mobile web app [ 69 ]
Communication Tools
The usual views per day, per week, and per month are available in each case.
Access using a fat client Gmail
Accessing Gmail by means of a standalone client application (like Outlook, Thunderbird, or Apple Mail) has the advantage that users familiar with this kind of interface can still use their favorite tool. To make such access possible, the first thing to do is to enable the IMAP protocol in the Gmail settings, as we explained earlier. The specific local settings will of course depend on the application. The list of supported clients keeps growing and is available on the Gmail help center. Keep in mind that the IMAP protocol maps the label concept, which is unique to Gmail, to the notion of a folder. A label corresponds to a folder, with inevitable redundancies that follow: a message having for instance the labels "administration" and "projects" will be stored in an "administration" folder and, simultaneously, in a "projects" folder. We'll also mention that the IMAP protocol translates each "/" into a corresponding folder hierarchy. The notion of a conversation has no equivalent in IMAP and will thus be omitted from the display in the mail client. More generally, here is a table that shows the correspondence between the actions on an IMAP client and the result obtained in the web version of Gmail: Matching the actions on an IMAP client and the corresponding result on Gmail. Action on the IMAP client Open a message Mark a message Move a message to a folder Move a message to a subfolder Creation of a folder Move a message to [Gmail]/Spam Move a message to [Gmail]/Corbeille Send a message Delete a message from the inbox Delete a message from a folder Remove a message from [Gmail]/Spam or [Gmail]/Corbeille [ 70 ]
Result on Gmail Marks the message as read Starring a message Apply a label to the message Apply a label to the message showing the hierarchy of folders Creation of a label Tag the message as being spam Put the message in the trash Tag the message with "Sent Mail" Delete a message from the inbox Delete the corresponding label Permanently delete the message
Chapter 3
The behavior may vary slightly however from one client to another.
Google Calendar
Accessing one of the Google Calendars in read-only mode basically amounts to using its private URL with the appropriate format: XML or iCalendar, as we explained in the section on import/export capabilities in Google Calendar. To maintain two-way synchronization, the most commonly used protocol is Microsoft® Exchange ActiveSync®. The detailed configuration again depends on the application.
The offline mode
The offline mode allows using most features in Gmail and Google Calendar in a web browser, even when no network connection is available. This feature was specifically designed for the nomadic uses of the Google Apps in a professional setting:
Icons indicate the synchronization status. From left to right: no connection available (offline mode is being used), the system is currently being synchronized, the system is synchronized.
At the time of writing (2010), it is necessary to install a plugin named Google Gears to use this feature. An exception is if you use Google's own browser Chrome in a recent version. The Google Gears plug-in can be freely downloaded from the Google Apps site. The upcoming release of HTML 5 will however make this plugin obsolete because this new standard will incorporate cache features. Google is an active promoter of this new standard.
[ 71 ]
Communication Tools
Gmail
Once the Google Gears plugin has been installed, the synchronization process starts. The process may take a few hours when many years of correspondence are being backed up this way.
The icon that indicates that all messages have been synchronized locally and that they will remain accessible offline
Once the synchronization process is complete, all Gmail tools (text editor, searching messages) will remain available offline, including viewing mail attachments.
Google Calendar
In most respects, the synchronization process is similar to Gmail, except that it is much faster. For now, the calendars are only accessible in read-only mode while offline. Moreover, it is not possible to create any new events or to send invitations either.
Summary
This chapter has presented the main features of both communication tools from the Google Apps suite: Gmail and Google Calendar. Among the notable features of Gmail we presented: the labels that can be used to efficiently organize messages, the search tools, and the steady improvement of the service using the Google Labs that allow the most motivated user to test new features while they are still in an experimental stage. The Google Calendar tool is very much integrated with Gmail, namely through its notification and reminder services. Both services are designed to be accessible from anywhere on any channel. Both have simple and efficient privacy management.
[ 72 ]
Collaboration Tools This chapter presents the Google Apps collaboration tools, starting with the Google Docs office suite. We will discuss how it differs from a traditional office suite and what advantages it offers for collaborative work. The integration with the communication tools presented in Chapter 3, Communication Tools will be addressed frequently, as will issues of privacy and rights related to the sharing of documents. The tool for creating websites, Google Sites, is presented next. The final section is devoted to a quick overview of Google Video, a video sharing solution.
Google Docs How does Google Docs differ from a conventional Office Suite?
Google Docs has all the benefits inherent in a SaaS solution (see Chapter 1, Google and the Basics of Cloud Computing), namely that no installation is required on the client, updates are periodic and automatic, and all data is stored in the cloud. We'll also mention the possibility of sharing and collaboration, which provides significant productivity improvements when compared to a more conventional office solution. Google Docs benefits from its integration with other Google Apps, the most important of which is Gmail, which allows using Google Docs for viewing attachments. Google's solution for creating websites, named Google Sites, also benefits from its integration with Google Docs, allowing inserting documents and spreadsheets in web pages.
Collaboration Tools
For the time being, the features and the level of user-friendliness proposed by Google Docs do not yet meet the standards of a conventional suite like Microsoft's Office or Apple's iWorks. Current HTML technology does not yet provide drag and drop within a web page. For this reason, Google Docs is best suited in situations where the benefit of collaboration outweighs the need for a sophisticated layout or the need for advanced UI capabilities. However, a number of solutions in the Google Apps ecosystem try to compensate for some of these deficiencies, including products such as OffiSync, Memeo Connect, Syncplicity, and Docverse. The above mentioned are either applications developed by Google (Docverse) or Apps that are available on the Marketplace. Some of them are described in Chapter 11, Third-party Extensions which discusses various extensions proposed by partners. Thus, Google Docs could be used, for instance, during the first phase of writing a document while collaborative work is particularly important. Once the text has been agreed upon by the collaborators, the document can be exported to one of the usual formats to be edited by a more conventional tool, to adjust its layout precisely and include sophisticated graphics.
Word processing with Google Docs Creating and editing text documents
The GUI attempts to mimic that of a standard word processor such as Microsoft's Word, or pages from Apple or Writer from the open-source OpenOffice suite, with its menus and tools for layout:
The interface of Google Docs largely reproduces the usual interface of a desktop word processor
[ 74 ]
Chapter 4
Copy-paste is available between applications in Google Docs. In most situations, the classical CTRL + C (Copy) and Ctrl + V (Paste) are operational. In some situations, however, a better option is to use the contextual menus, which will then use the clipboard associated with the Google Apps account. In this way, the content is copied and stored on the server side and can be reused from one computer to another at any time. For the time being, the creation and storage of a document in a directory happens in two stages. It is not yet possible to directly create a document in a folder. By default, newly created documents are not contained in any folder. In fact, the folders work just like Gmail labels that we described in Chapter 3, Communication Tools hence each document can be stored simultaneously "in" multiple directories.
Searching for documents
The standard search options, using the usual criteria (as shown in the following screenshot), are available—search for documents whose name contains a given string or search a specific document for a string within its contents:
Left, the search form in Google Docs. Center, the various categories of documents. Right, sorting of document in chronological order.
Multiple categories of documents are predefined. This allows you to search for documents belonging to only one of these categories. It is also possible to search for a document according to ownership or depending on who is sharing it. For newly created documents, chronological search can be especially convenient. Finally, it is of course also possible to just open a folder to browse its content.
[ 75 ]
Collaboration Tools
Accessing document history
The history revision feature is particularly useful. It allows you to retrieve, at any time, a document in the exact state it was at the moment it was saved. A comparison tool is also available for highlighting changes from one version to another.
The history of the successive revisions of a document in the comparison tool
This is an advantage compared to most conventional word processors that usually do not offer such an easy access to the revision history of a document. Once an older version of a document is restored, all collaborators will see this version. A "most recent" button allows you to restore the most recent version. When copying a document, only the most recent version is copied.
Using Google Documents as attachments
Each Google Document can be sent as a Gmail attachment or can be directly included in the body of the message. The usual formats are available, namely HTML, PDF, RTF (Rich Text Format), TXT (plain text), and .doc (Microsoft Word 97-2003 format). Another possibility is to send a link pointing to the Google Document. Conversely, when an Office document is attached to a mail, it can be converted on-the-fly into a Google Docs document.
[ 76 ]
Chapter 4
Google Spreadsheets
As with any other tool in the Google Docs suite, Google Spreadsheets interface closely resembles that of a more traditional spreadsheet tool like Microsoft's Excel or Apple's Numbers.
Creation and editing of spreadsheets
The creation, sharing, and deleting operations for spreadsheets are all similar to those for a text document. Hence, we shall focus here only on the differences. One important difference is related to how spreadsheets are saved. Currently, spreadsheets are saved automatically: no action is required from the user. Spreadsheets were designed for real-time collaboration between several users where each of them can modify different cells of a single document. Each user sees the updates in real time, while they are being typed by a collaborator. This real-time collaboration requires automatic saving. The next section is devoted to collaboration, so we shall come back to these questions in more detail later. Features for a spreadsheet are the classical ones, which we'll look at next.
Tabs
Just as in a conventional spreadsheet, a document is organized in tabs. A user can add as many tabs as desired:
Creation of tabs with Google Spreadsheet
Tabs can also be moved.
[ 77 ]
Collaboration Tools
Formulas
Formulas are especially useful for organizing documents and performing elementary statistical operations. Here again, you'll find the usual features that can be expected from a conventional spreadsheet. In particular, there is a long list of predefined functions sorted by category: mathematics, finance, logic, date-time functions, statistics, string manipulation, and so on. An auto-complete mechanism is available, which facilitates typing complicated formulas (as shown in the following screenshot):
Auto-completion for formulas
Each function has thorough online documentation. A formula can be applied either to a single cell or simultaneously to many cells.
Computing the total for a column. The formula which computes the total of column A may be applied to columns B and C with a simple drag and drop.
The result of a formula can comprise several cells: the TRANSPOSE() function is such an example, for which the result is a matrix.
Formats and display rules
Many different formats are available for dates, currencies, decimal numbers, and percentage. It is possible, moreover, to define conditional formatting rules for how things should be displayed depending on the value of a cell. This can prove particularly useful to highlight statistically exceptional values.
[ 78 ]
Chapter 4
Defining display rules based on the cell content
It is also possible to merge cells, to add borders to them, and to freeze rows or columns.
Data validation
Validation helps improve the quality of data entered in a spreadsheet. Constraints can be defined and linked to a set of cells. These constraints may relate to numbers, character strings, or dates.
Defining a data-validation constraint for a set of cells
An option may be selected that makes it possible to enter data that violates the validation rule.
[ 79 ]
Collaboration Tools
Charts, drawings, and gadgets
Charts and gadgets are dynamic objects that represent data on a spreadsheet. They are automatically updated as soon as the underlying data changes. These gadgets are often interactive objects like the map in the following figure:
Top left, a chart (histogram) that displays the values 1, 2, and 5. Top right, a map gadget, which shows the position of three cities. Bottom left, a static drawing.
Here are a few differences between charts and gadgets: •
Charts: °
•
•
They are intended for vizualizing statistical data (histograms, curves, sets of points and so on).
Gadgets: °
There exists a large variety of them (charts, tables, maps, financial charts, and so on) adapted to usages that go far beyond a simple representation of statistical data.
°
Users can create their own gadgets. They help make spreadsheets more interactive.
Common gadget features include: °
The possibility to be publised as a web page.
°
The possiblity to be saved as a .png image.
°
The ability to update themselves automatically each time the underlying data changes.
Drawings and static images can also be integrated in spreadsheets. [ 80 ]
Chapter 4
Creating forms
When several people must simultaneously fill in a spreadsheet, the simplest solution is to create a form and to send it to them with Gmail. A "form" is actually a specific type of document in Google Docs (as shown in the following screenshot):
Creating a form to have several people fill in a spreadsheet
A form contains a list of questions, each pertaining to the value of one field (or column) that will be entered in a spreadsheet (as shown in the folowing screenshot):
The form as it appears in the mail of the recipient and the spreadsheet as it appears to the sender. In this example, two users have submitted the form.
When creating a form, it is possible to require the name of each user who enters data. This information will then be displayed in the spreadsheet. The inverse operation, that is, the creation of form starting from a spreadsheet, is possible as well.
[ 81 ]
Collaboration Tools
Google Presentations
Google Presentation is very similar to PowerPoint from the Microsoft Office Suite, Keynote from Apple's iWorks Suite, and Impress from the open-source Open Office package.
Creating, editing, and organizing a presentation
Unless you use a template, creating a presentation is a two-step process. First, you choose a theme for the presentation and then, for each slide, a layout:
Choosing a theme for the presentation, then choosing a layout for each slide. On the right, the slide sorter.
Slides can be sorted and rearranged the usual way, using drag and drop.
Inserting images and videos
Images can be inserted either by uploading a local file or by pointing to an image on the web identified by its URL. Videos from YouTube can be also be used in Google Presentation, however it is not possible, unlike for images, to upload a local video file.
Making a presentation
Google Presentation has a full-screen mode for showing slides in public. A presentation can be followed simultaneously by several, distant participants. Each of them can choose to follow the presentation as shown by the speaker or they can take control of the slideshow at their own pace. A speaker can choose to display his or her own notes. The editors (see the following figure) can choose to take full control of the presentation if they like. A chat module is available to all participants so that they can exchange messages during a presentation. [ 82 ]
Chapter 4
Google Drawing
Google Drawing is a collaborative drawing tool with features very similar to those proposed by PowerPoint, for instance.
The collaborative drawing tool in Google Docs
Just as for any other kind of document, drawings can be shared. They can be exported in the most common formats like PNG, JPEG, SVG, PDF. Real-time collaboration and parallel editing by several collaborators is available. Instant messaging is also integrated into the tool. Drag-and-drop of pictures works with any other Google Docs document.
Sharing documents
The primary use of Google Docs is sharing documents and simultaneous collaboration on a document for several users. The way access control lists (ACL) are defined is particularly simple; there are just three roles: •
Viewers can read the most recent version of a document. They can also export a document.
•
Editors can modify a document. Provided they were granted the rights by the owner of the document, they can invite and remove other editors.
[ 83 ]
Collaboration Tools
•
Owners have the same rights as editors but in addition they can delete a document and change access rights. To permanently delete a document and prevent any further access to it, an owner should put it into the trash and then empty it.
The owner of a document can grant other users the right to edit and invite other editors
When an owner deletes a document he or she is given the chance to reassign it to a new owner. There are actually two different ways to share a document, depending on whether authentication is required or not.
Sharing a document with authenticated users
To share a document with authenticated users, you can either do it directly or select it from the list of documents. Sharing is not limited to users who belong to a Google Apps domain and can include any address attached to a Google account.
Two different ways to activate the sharing of a document
[ 84 ]
Chapter 4
You can also share a document with all users from a Google Apps domain.
Sharing a document using a link
This type of anonymous sharing is only possible if it has been explicitly enabled by the domain administrator (see the Google Docs section of Chapter 7, Managing a Google Apps Domain). You just need to send a link to the person with whom you want to share the document:
You can also specify whether you want to allow people who have the link to edit the document.
Publishing a document as a web page
Publishing a document as a web page is another possibility for sharing a document in read-only mode. The body of the text will be published as a simple web page, with no menu and no toolbar. For security, the administrator of the domain can restrict the visibility of such public web pages to the users belonging to the Google Apps domain (see the corresponding section in Chapter 7, Managing a Google Apps Domain for details). An option automates the publication of updates to the web page for each change in the original document. The document will not be indexed by Google's search engine even though it is publicly available.
[ 85 ]
Collaboration Tools
Collaborating on a document
The way the list of the collaborators who are currently editing a document is displayed differs slightly from one app to another.
The list of the collaborators who are currently editing the document
A document whose last version has not yet been opened appears in boldface in the list of documents. The number of collaborators and the last person who modified the document are also shown:
The documents whose latest version has not yet been opened appear in boldface
Real-time collaboration with spreadsheets
Google Spreadsheets allows you to define very precise notifications when a document is modified, even down to the level of individual cells:
[ 86 ]
Chapter 4
Detailed specifications of notifications are available for spreadsheets
Changes made by collaborators appear instantly in the browser.
Real-time collaboration with text documents
Similar features are available for Google Doc's word processor. Simultaneous updates from several collaborators are possible here, too. Changes show instantly in the browser and a label indicates who is making which change:
The names of the collaborators appear on the top right of the window. Changes are shown instantly and are labeled with the name of the collaborator making the change.
Protecting spreadsheets
The owner of a spreadsheet can choose to protect it by selecting which collaborators are actually allowed to make changes:
Defining the editing rights for a spreadsheet
[ 87 ]
Collaboration Tools
There are no limits to the number of collaborators or number of documents in the new generation of editors.
Using templates
Using templates can be a good way to quickly create documents that adhere to some predefined visual identity or layout. There are many public templates that are sorted by category for any kind of Google Documents. This way, any organization can easily define visual identity guidelines implemented by various templates. Finally, users can define a set of templates for their own use. Any Google Document can be made into a template.
Using templates allows quick creation of documents that adhere to some predefined visual identity or layout
Importing and exporting documents
Files with the usual formats for office documents can be imported into Google Docs. When importing an Office document, Google Docs by default converts it into a Google Docs document. It is possible though, to skip this step and save a document in its original format. A limit of 250 MB per file applies in this case. There is also a 1GB global limit per user.
You can choose to convert an imported document into the Google Docs format or to leave it as it is
During the conversion process, some details of the layout may not be preserved. Therefore, it is a good idea first to perform some tests to ensure that the level of resemblance to the original is appropriate. Sometimes, simplifying the original layout may prove useful.
[ 88 ]
Chapter 4
Text documents
The following formats are accepted as input documents: HTML, plain text (.txt), Word (.doc et .docx), RTF (Rich Text Format), OpenOffice (.odt), and StarOffice Writer (.swx). The following formats can be used for exporting: HTML, RTF, Word, Open Office, PDF, or plain text. To be converted into Google Docs format, documents should not exceed 500 KB (for the converted document) plus 2MB per image included in the document. Furthermore, a limit of 5000 documents applies.
Spreadsheets •
The following formats are accepted as input documents: Microsoft Excel (.xls, .xlsx), OpenDocument (.ods), .csv, .tsv, plain text (.txt)
•
The following formats can be used to export: .csv, HTML, .ods, PDF, .xls, raw text (.txt)
•
Each imported spreadsheet can contain at most 256 columns, 200,000 cells, and 100 tabs
•
Each spreadsheet can at most contain 20,000 cells with formulas
•
No more than 1000 spreadsheets can be stored per account
•
No more than 11 spreadsheets can be opened simultaneously
•
Imported document should not exceed 1MB
Presentations •
The two PowerPoint formats .ppt and .pps are available for import and export. PDF is available for export only
•
An imported presentation should not be larger than 10 MB and should not contain more than 200 slides
•
Presentations sent by mail should not be larger than 500 KB
•
No more than 5000 presentation per account and no more than 5000 images
[ 89 ]
Collaboration Tools
The offline mode
Viewing a document offline is possible, provided the Google Gears plugin has been installed. Google Chrome natively includes this feature. Text documents can even be modified offline. For the time being it is not yet possible to create documents in the offline mode. The icons that indicate the synchronization status are the same as those we already described in Chapter 3, Communication Tools.
DocVerse
DocVerse is a plugin for Microsoft Office applications that turns these tools into collaborative web-enabled tools. DocVerse was acquired by Google in early 2010 and it is expected that DocVerse will eventually be fully integrated with Google Docs. DocVerse is an interesting alternative to the online Google Docs for those users who don't want to give up their favorite productivity tools.
The DocVerse panel in Office tools. It includes a URL to access the document online, a chat tab, and a history tab.
For the time being, any document saved with DocVerse is also available in the cloud for reading and for commenting but not yet for editing. DocVerse includes an instant messaging tab that allows collaborators on a document to instantly share their comments. Each successive version of a document is incrementally stored in the cloud. DocVerse currently handles documents from Word, Excel, and PowerPoint formats in the Office 2003 and 2007 editions. A free, trial version is available on the DocVerse website. [ 90 ]
Chapter 4
Google Sites Between a Wiki and a Content Management System
Google Sites is an online web content management tool that can help you to quickly create a website. It can be compared to other tools like Drupal, TYPO3, or Joomla!, but with added collaborative functionality. The design of Google Sites is similar to a wiki. Several users can collaborate to build a website. One possible use of Google Sites is to aggregate data from other Google Apps, like Google Docs, Google Calendar, video, or simply text. To facilitate the creation of a new site, Google Sites provides a large selection of templates both for whole sites and individual pages. A common use for Google Sites is the creation of a website dedicated to a project team.
One template for each use
The creation of a website starts by choosing a template. It defines the type of pages used (as shown in the following screenshot), the navigations links, and the graphical theme which comprises fonts and background images:
Choosing a site model in the gallery
[ 91 ]
Collaboration Tools
A template can be visualized before it is used. If no template is available, it is possible to start with an empty template and then select a graphic theme that will ensure a consistent look and feel for the site (as shown in the following screenshot):
Choosing a theme starting with a blank page
In any case, the layout and graphical options remain editable at any time. The single most important element in a website is probably its navigation menu. It can be modified in Google Sites:
Changing the navigation menu in the sidebar. By default, the menu is organized according the hierarchy of pages and sub-pages.
In Google Sites, each page is a node for a set of subpages as we will see shortly. Usually, the main navigation menu reflects this hierarchical structure. By default, Google Sites organizes the menu automatically by letting users choose the depth of the tree. For specific uses, this behavior can be modified. Finally, an interesting feature is the possibility to store any Google Site as a template. Any modification of the original site will immediately propagate to the template.
[ 92 ]
Chapter 4
Creating pages The five types of pages
With Google Sites, it is possible to create five different kinds of pages that structure information in various ways. In addition to formatted text, links, images, videos, Google Docs, and even raw HTML code can be added.
The five types of pages proposed by Google Sites
Web Page This is an unstructured page in which you can add formatted text, images, and tables. More complicated layout can be obtained by nesting tables within tables. Announcements This is a blog like page on which a visitor can leave their comments. It is used mainly to keep track of information in chronological order. A team can use it, for instance, to publish information on key events. File Cabinet Page This kind of page allows you to upload local documents to a web page and organize them into a hierarchy of folders. List Page This page allows visitors to easily add items to a list or to a table. An example use we can think of for this type of page would be an elementary bug tracking system where each new defect is notified by adding a short description to an existing list of bugs. Start Page This kind of page allows users to customize their start page and add gadgets to it. It can also contain shared content visible to any collaborator.
[ 93 ]
Collaboration Tools
Each page can be saved as a template and saved for later use.
Accessing the history of a web page.
All versions of any page from a site are kept in the site history, which is accessible to any of its collaborators.
The three categories of objects
Objects that may be used in a web page fall into one of three categories:
The three categories of objects that can be inserted in Google Site web page
The "non-Google" objects: images, URLs, or reference lists. The Google objects: objects created within other Google Apps such as Google Calendar, Presentations, Spreadsheets, Google Docs, and videos from Google Video. These objects implement the integration between Google Sites and the other apps from the suite. The gadgets: these are modules published on the web and that are categorized as "News", "Finance", or "Technology" and that mostly bring interactivity to Google Site's pages.
[ 94 ]
Chapter 4
Using gadgets allows, for instance, combining Google Sites with workflow tools (such as RunMyProcess that we shall discuss in Chapter 11, Third-party Extensions) to create dashboards fed by various sources of information.
Defining access rights for collaboration
A Google Site can be made public to the whole Web or its visibility can be restricted to users from a Google Apps domain or even only to a subset of those. The access rights for Google Sites are quite similar to those of Google Docs; they rely on three roles: •
The readers can only see pages of a site but not modify them.
•
The editors can create modify or delete pages. They can add comments to announcement pages and add attachments to file cabinets pages. They can also change the navigation menu and subscribe to notifications for any changes that are either on the site as a whole or only to specific pages.
•
The owners (there can be many of them) can moreover invite other collaborators, and modify the themes and the layout of pages. They are the only ones who can delete the sites.
•
The administrator can decide to add more restrictions (for more information on this topic, see the section devoted to Google Sites in Chapter 7, Managing a Google Apps Domain).
Google Video
Google Video is best compared to a sort of private version of YouTube. Each Google Apps deployment allows sharing and publishing videos in a way that is very similar to what can be done with Google Docs and Google Sites: •
Readers can view videos, evaluate them, and add comments but they can neither change them nor share video files
•
Editors are allowed to change videos and share them
[ 95 ]
Collaboration Tools
•
Owners can also delete videos, in addition to what editors can do
Forms for sending a video
Any user in a Google Apps domain can be granted one of these three roles. When sending a video, an owner can choose to share it, either with a list of collaborators or to make it available to anybody in the domain. The owner can choose to allow the download of a video. The size of a video should not exceed 16GB with Google Gears and 3GB otherwise. The domain administrator can enable or disable the video service.
Summary
This chapter discussed the main collaboration tools in the Google Apps suite, namely the office suite Google Docs and the content management system Google Sites. The main strength of these tools lies both in their mutual integration and the simple access rights model they share.
[ 96 ]
Security Tools This chapter discusses the security tools that come with Google Apps. The first section provides an overview of the main security components and explains how they are related: the antivirus filters, the spam filters, filter rules, the quarantine for suspicious messages, and the archiving facility. The next section then describes the security tools available to any Google Apps users and more specifically the console called the Message Center that provides secure access to quarantined messages and search tools. The final section goes into more detail to describe the main tasks that are the responsibility of a Google Apps domain administrator.
Overview
Safety for incoming mail, sent to recipients belonging to a Google Apps domain, or for outgoing mail, sent from that domain, is provided by a toolkit named the "Postini services". The name is that of a specialized start-up, which was acquired by Google in 2007. We can schematically group these tools in two categories: first the tools for ensuring the safety of messages and second, the tools for archiving and searching through the messages. Archiving tools are optional and in fact require a subscription in addition to a Google Apps for Business Edition subscription. Among the many security features, the most important ones are the following: •
Content and attachment filters. This type of filter is generally designed to enforce a company's policy regarding incoming or outgoing messages.
•
There are also TLS encryption mechanisms for secure inbound and outbound message exchange.
•
Antivirus filters and anti-spam filters beyond the existing mechanisms in Gmail.
Security Tools
•
A console called Message Center, which allows users to manage their own quarantined messages and define their own lists of approved or blocked addresses.
Among the features offered by the archiving tools let us mention: •
A centralized archiving facility for all emails of all users in a Google Apps domain.
•
Monitoring tools and search tools.
•
A personal archive that allows users to access their messages and to recover them as required.
Security and archiving tools are described schematically in the following figure. The filters dispatch suspect messages to quarantine where they can be read safely. A copy of each message that passed all filters is sent to the archive. Quarantine
Blocked message
Internet
Message security anti-spam filter anti-virus filter regulatory filter
Gmail
Copied message Searching for messages Message archives Personal archives
Incoming messages flow through antivirus and anti-spam filters. There are also filters that enforce policies on specific message content. Suspect messages are blocked and sent to quarantine. A similar pattern applies for outgoing mail and messages within a Google Apps domain.
Besides securing a Google Apps domain, Google Postini services also offer an interesting failover system named Google Message Continuity, for companies which choose to keep their Microsoft Exchange mail server.
[ 98 ]
Chapter 5 Gmail 2
Sender/ Recipient
3
4
1
Postini
Google Sync Server
Recipient/ Sender
2
Microsoft Exchange Server
Email flow diagram, when using Google Message Continuity
Google Message Continuity will ensure rapid failover in the event of a server outage. Email replication will automatically take place and users will be able to check their mail using Gmail in case of a failure of the on-premise mail system. Google Message Continuity actually includes all security features of Google Message Security and requires no hardware installation. It is managed through a simple web interface.
The Message Center and the personal archive
The security features described in this section are available to users, provided they have been activated by the administrator.
The Message Center
The Message Center is a web console, that allows users to manage the messages that were routed to their quarantine and which gives them an access to their personal archive.
The Message Center includes a set of tools that allow users to manage the messages that were put into quarantine and to access their personal archive
[ 99 ]
Security Tools
The Postini system periodically sends a summary to each user with a list of spam and suspect messages that were quarantined since the last summary. The message contains a link to the Message Center where messages can be inspected safely. Here, we will provide a description of the main features of the Message Center, in the same order in which they are organized in the tabs.
The quarantine for spam
The following figure shows the spam quarantine. By consulting this quarantine regularly, users can identify messages that were wrongly identified as spam and recover them. They can also adjust the anti-spam settings (see the following). By default, this quarantine is available to each user in the domain.
The quarantine for infected messages
The quarantine for messages infected by viruses is very similar to the previous one. Users are sent a mail notification when an infected message is put in the quarantine. Actually, if the domain administrator takes no special action, infected messages are simply deleted and thus users will find their quarantine empty. This behavior can be changed, however (see the following).
The infected message quarantine in the Message Center
The Message Center allows reading an infected message under safe conditions. By default, Postini simply deletes infected messages. Users won't see them in their quarantined messages. For infected messages to be available for reading, the administrator should first enable archiving.
[ 100 ]
Chapter 5
The early detection quarantine
This quarantine stores messages that were identified as zero-hour threats, even though a formal virus signature has not yet been recognized. By default, this tab is not shown in the Message Center. This quarantine works the same way as the usual infected message quarantine. Safe reading of messages is guaranteed. Here again, users are notified by mail when one of their messages is put in this quarantine.
The personal archive
This tab is only available if you have subscribed to the Message Discovery Service that comes as a complement to the Google Apps for Business Edition subscription. All messages from all users are stored for a period of time that must be specified when subscribing to the Message Discovery service. Users can, in particular, recover the messages that they deleted by mistake. It is important to note that once a message has been archived it cannot be changed anymore. This feature makes archiving suitable for legal purposes. The archiving period can last for decades.
The form that allows searching the personal archive.
The form offers the usual set of criteria such as: •
The name of the sender or the recipient
•
Dates which delimit a search period
� ���� The ���� aim ����������� here is to ������������������������ detect new viruses even �������������������������������� before a formal virus signature ���� has ���������������� been identified ���� and ����������� before the antivirus bases can be updated.
[ 101 ]
Security Tools
•
Strings of characters to search for in the body of the text, the subject or the name of an attachment
•
The existence of an attachment
Defining Options Defining Whitelists
With Postini, a domain administrator can define lists of users, domains, and mailing lists that won't be analyzed by any of the message filters. Messages from those sources will be routed to their recipient's mailbox without any further analysis.
Defining Blacklists
Conversely, it is also possible to define a list of users who will be blocked systematically. Messages from these sources will automatically be labeled as spam and then routed to the corresponding quarantine.
Defining a threshold for the anti-spam filter
There are two kinds of settings for tuning the spam filter. First, there is a parameter that defines a global level of tolerance for all kinds of illicit content. Then there are separate parameters that control the level of protection for each category of illicit content.
The threshold for the spam filter is adjusted by setting two kinds of parameters: a global one and one per category of illicit content
Increasing the value of either parameter increases the chances that a message is put into quarantine. When high values are chosen, it is a good idea to regularly check the quarantine to ensure that none of them were wrongly quarantined. [ 102 ]
Chapter 5
The main administration features
The primary tasks for a domain administrator, regarding Postini services, are: to enable or to disable the Google Apps services, to define categories of users, and to grant them different rights for different applications. The Postini console should not be confused with the Google Apps administration console (which we shall cover in Chapter 7, Managing a Google Apps Domain).
The administration console for the Postini services
Once the Postini services have been activated, each user is granted default rights. These can be changed later by the administrator, either globally or individually. This last possibility is not recommended, however.
Managing user accounts Creating users and organizations
In the Postini administration console, users in a Google Apps domain are arranged into hierarchies of organizations:
The hierarchy of organizations in the Postini console
[ 103 ]
Security Tools
By the time the system is activated, this hierarchy contains only two organizations. At the top level, there is the «Account Administrators org», which groups the administrator defined when the system was activated and a template user account called Default User. This model defines default user authorizations for any newly created user in the domain. Directly below the «Account Administrators org» we have «Users org», which contains all user accounts that were originally defined in the Google Apps console (see Chapter 7, Managing a Google Apps Domain). Creating sub-organizations in this hierarchy is the preferred way to grant specific rights to some categories of users. By default, each sub-organization inherits the rights from the organization which is immediately above in the hierarchy. These default rights can be modified or refined.
Default authorizations
Administrators who are in charge of security should be aware of the default rights granted to users regarding their access to the Message Center. The following list summarizes the most important ones. By default, each user is granted the following authorizations: Security or Search Feature
Access
Enabling/disabling the anti-spam filter
Granted
Modifying the global threshold of the anti-spam filter
Granted
Modifying the threshold of the explicit content filter
Denied
Disabling the antivirus filter
Denied
Changing the locale
Granted
Searching the personal archive
Granted
Recovering messages from the personal archive
Granted
Reading the reasons for why a message was routed to quarantine
Granted
Having a message analyzed
Denied
Reading the attachments of a message in the quarantine
Granted
Default access rights granted to users
Defining user authorizations
One of the primary tasks for an administrator is to grant authorizations to the users of the domain being administered.
[ 104 ]
Chapter 5
Defining the set of authorizations for a specific user
Managing filters for Gmail
Considering the complexity of the Postini console, we will not attempt here a thorough coverage of each feature. That would far exceed the scope of this book. We will only present the most important ones and we refer the reader to the online documentation for more detailed information. Recall that the various settings apply either to specific users or to organizations. Options are not quite the same in both cases, as the following two figures show:
The settings for the Postini services for a user organization
������������������������������������������������������������������������ The full documentation for Postini services is available online here:
http://www.postini.com/webdocs/admin_msd/ [ 105 ]
Security Tools
The settings for the Postini services for a specific user
The Antivirus filters
When a message infected by a virus is received, the default behavior of Postini is the following: •
Return the message to the sender whether it is inbound our outbound
•
Delete all infected messages whose recipient does not correspond to any user defined within the Google Apps domain
Individual user accounts
The administrator can enable or disable the antivirus for each account.
User organizations
The administrator can choose to route messages to the quarantine rather than sending them back to the sender. The administrator can also decide to send messages whose recipient is unknown to a specific account. The early detection mechanism may route some messages that were only suspected to be infected to the provisional quarantine (for a period of 8 hours); they will be analyzed further once the malware database has been updated. The administrator can enable or disable this service.
The anti-spam filters
We indicate below which settings can be adjusted for the spam filter, both for individual users and for user organizations. Recall that messages whose recipients are on a white list (defined either by the user or the administrator) automatically bypass any filtering.
[ 106 ]
Chapter 5
Individual user accounts
The administrator can enable or disable the spam filter, adjust its global threshold, and the threshold for different categories:
Adjusting the anti-spam filter.
User organizations
At the level of an organization, the user can define the following parameters: •
Enabling "return to sender" and deleting blatant spam
•
What to do with messages that lack an SMTP envelope: return to sender, route to quarantine, or delete
•
What to do with usual spam: route to quarantine, route to the quarantine of a specific user, or tag the message for separate processing on the mail server
Content filters
This category of filter analyzes the content of messages and attachments in order to identify illicit or confidential content. Specific words or patterns of characters can be declared as illicit and blocked. These filters are defined at the level of an organization. Among the most common uses, let's quote, for instance: •
Blocking illicit content
•
Routing messages to quarantine when outbound messages with proprietary and confidential content are detected
•
Routing messages to quarantine when outbound messages with private information or credit card numbers are detected
•
Monitoring inbound and outbound messages but letting the recipients receive their mail
� ���� The ����������������������������������������������� definition of this term is of course up to the �������������� administrator ����������� and is not ��������������������������������� part of the technical vocabulary in Postini!
[ 107 ]
Security Tools
When messages are routed to the quarantine, a user will find them in his personal quarantine. The column labeled "reason for blocking" will display "Content" in this case. It is also possible to route illicit messages to the administrator's quarantine rather than to that of the user. Regular expressions are a powerful tool for defining patterns of characters such as URLs, social security numbers, or account numbers. It is actually a standard notation used in many scripting tools such as PERL, for instance. Without going into too much detail, here are a few examples of useful regular expressions: •
To filter URLs containing "badmail" use the following regular expression: badmail(\w.+%\-){0,25}\.com
•
To filter a word such as "Viagra" including many different spellings, use the following regexp: v[i!1][a@]gr[a@]
•
To filter a list of words such as (word1, word2, word3 word4) use the following regexp: (\W|^)(word1|word2|word3\word4)(\W|$)
The Postini system supports the POSIX Extended Regular Expression (ERE). The order in which the filters are applied has its importance in defining the result of filtering. This order can be changed at any time.
An ordered list of content filters. The first two are the predefined filters. The last one was defined by the administrator.
A content filter is defined by at most three rules; each of them specifies the scope of the search and the type of rule that is being enforced. Either all rules apply or at least one of them.
������������������������������������������������������������������������������������������������ . This is often abbreviated "regex". Information on regular expression syntax can be found here http://www.regexlib.com/.
[ 108 ]
Chapter 5
A filter is defined by at most three rules.
Each filter from a list can be separately enabled or disabled. The action to take when a message is caught can also be defined for each filter. Predefined filters cannot be deleted but can be disabled.
Attachment filters
Like content filters, attachment filters are defined at the level of an organization. Among the most common uses for this kind of filter, let us mention, in particular: •
Block inbound or outbound messages whose attachments are too large
•
Block messages that contain at least one executable file in their attachments
•
Block messages that contain at least one file whose type is prohibited by the enterprise's security policy
Summarizing, filtering on attachment is both on the type of files and their size. The settings that can be adjusted are: •
The email address of the users whose mailbox will be used in case of quarantine routing
•
The error message to display when mail is returned to the sender
•
The maximum size of an attachment (<20 Gb)
For each kind of file (executable, archive, Office document, image, sound, multimedia, and so on.) the administrator can define one of the following kinds of actions: •
Approve the message
•
Return the message to the sender with an error message
•
Route the message to the user's quarantine [ 109 ]
Security Tools
•
Route the message to the quarantine specified by the administrator without sending it to the original recipient
•
Route the message to the quarantine specified by the administrator while at the same time routing it without any warning to the original recipient
It is also possible to identify attachments through binary analysis rather than by the file extensions and to enable the analysis inside compressed archives.
Defining notifications
The quarantine summary is a message sent automatically by Postini. It contains the list of the messages that were recently routed to the quarantine. The frequency of these messages can be defined by the administrator but cannot exceed one per day.
An example of a quarantine message that informs users when one of their messages is routed to quarantine or when one was deleted
Besides the quarantine summary, there are other notification messages that the administrator can enable: •
• • •
The welcome message informs new users when they connect for the first time that their messages are protected by Postini. The message also contains a link to the Message Center. The virus alert that informs the user that a message is infected and was put in quarantine. The early detection alert informs the user that a message was suspected to be infected by malware and was routed to the temporary quarantine. The message for the first spam alerts users that have never accessed their Message Center before that spam is being stored in a quarantine.
[ 110 ]
Chapter 5
Managing archives
Recall that the message archive securely stores a copy of each message that goes through the Google Apps systems except for spam. The administrator has full access to this archive and can also delegate those rights to other users. Finally, the administrator can choose to grant individual users the authorization to access their personal archives. The primary tasks of an administrator, regarding the management of archives, are the following: •
To make sure that all messages are actually archived, even those that were sent to unknown recipients, the administrator should disable in Postini the option that returns mail to the sender in case of an unknown user (NonAccount Bouncing).
•
Furthermore he must check that sub-domains were properly added to the Google Apps domain aliases and that MX-records were modified accordingly to have mail flow through Postini.
•
To avoid spam cluttering the archive, the option to automatically route towards a specific address in the case of an unknown recipient should be disabled.
Archiving can be enabled for a specific set of users. The maximal retention time for a message is 10 years, provided you have subscribed to the Message Discovery service for that period of time. Should the retention period be modified, it will only apply to the newly archived messages. The previous retention period remains valid for the messages that are already in the archive.
Optimizing the security settings Adjusting the anti-spam filter
As we have already seen, it is possible to adjust both an overall threshold and a threshold per category. Both kinds of settings have five levels. By default, the overall threshold is set to level "2" while the others are disabled. If the majority of users in a domain receive spam from just one category regularly, then, and only then, should the specific filter be activated. You should be aware, though, that specific filtering increases the chances that a valid message will be wrongly routed to the quarantine.
���� An ��� MX ���������������������������� record is a DNS record that ������������������������������������������������ determines toward which server a message should ����������� be routed.
[ 111 ]
Security Tools
Another possibility for the administrator is to delegate the responsibility of filtering to users themselves. Users should however be warned in this case that they should check the quarantine regularly to make sure no desirable messages were wrongly deleted by an overzealous filter. Clever usage of a few white lists and black lists that are updated on a regular basis often provides for the most efficient filtering.
Recovering a message from the quarantine
Both the Google Apps and the Message Security services from Postini have their own filters and their own quarantines. Therefore, when a user decides to recover a message that was routed to the quarantine, it may happen that this message is then considered as spam by Gmail's filter! The obvious solution is to explicitly declare this message as non-spam directly in Gmail.
Summary
This chapter discussed the Postini security (Message Security) and archiving (Message Discovery) tools by focusing first on what regular users can manage and then on the administrator's tasks. While they can look daunting in the first place, especially for the administrator, they provide a very coherent and powerful set of tools that ensure optimal security regarding both the content of messages and the automatic suppression of any kind of malware from the attachments.
[ 112 ]
Extending the Platform This chapter presents two different ways to extend the Google Apps platform. First, there is the Google Marketplace, a web store where customers can search for cloud services and purchase them. There are online applications, standalone client applications, and even services related to the Google Apps. Second, there is a Google Apps Engine for business, a platform for designing and hosting web applications that will benefit from the highly scalable architecture provided by Google's datacenters.
Google Apps Marketplace Introduction
Google Apps Marketplace is a website that offers to Google Apps customers a large array of services, either free or paid, which extend the Google Apps suite. Some products are also complements to the Enterprise Search service.
The homepage for the Google Apps Marketplace
Extending the Platform
We shall focus here on Google Apps products. They are split into three categories in the Google Apps Marketplace: desktop applications, online applications, and services. Sorting according to various business criteria is available. Here are a few examples. Chapter 11, Third-party Extensions will go into more details on some examples that we quote here: •
Document management: OffiSync is a plugin for the Microsoft Office suite, which uses the online storage facility of Google Docs and its collaborative tools.
•
Workflow tools: RunMyProcess. This allows users to design and deploy business processes based on Google Apps.
•
Administration tools: Spanning Sync helps synchronize a Mac or an iPhone with the Google Apps for everything related to calendars and contacts.
•
Project Management. Smartsheet is a project management tool using Gantt diagrams. This tools benefits from tight integration with Google Apps for notification mechanisms and collaboration. Excel documents or MS Project files can be converted into an online project.
•
Productivity tools: Shared contacts allows you to share contacts with users from other Google domains.
Searches can be performed by category:
Results of a search by criteria in Google Apps Marketplace
[ 114 ]
Chapter 6
Each product is reviewed by customers and a series of icons show the level of integration of the application with Google Apps:
These icons show, respectively, integration with Calendar, Google's universal navigation bar, SSO, Google Docs, and Google contacts
The Google universal navigation is a navigation bar that allows you to go from one Google app to another.
The Google universal navigation bar can integrate external applications
Installing an application
The only prerequisite to downloading an application from the Google Apps Marketplace is to have a Google Apps administrator account. The applications that need access to a Google Apps domain data must be granted these rights explicitly and for each API by the administrator when deploying the application. Once it has been installed, the application can be enabled immediately or the activation can be deferred. An application cannot however be uninstalled, only disabled. Usually an application will be available to users immediately after it has been activated. In some cases, their inclusion in the universal navigation bar can take more time, up to 24 hours. One important point to be aware of is that the data retention and protection policy for each application does not depend on Google and is entirely under the control of the vendor of the product. The best way to determine what happens to your data is to contact the vendor or to see what other customers say in their ratings of the product, or both. During the installation process, the administrator will be asked to accept or decline the contract terms. An explicit list of enterprise data to which the application needs access will be given at that time.
[ 115 ]
Extending the Platform
Google does not systematically review applications available on its Marketplace, as Apple does, for instance, on its App Store. Actually, anybody who is ready to pay 100$ for the inscription fee and who declares that they adhere to Google's conditions can propose a service on the Marketplace. However, each page presenting a product contains a form that allows customers to review an application and a form to report any possible abuse to Google.
Google App Engine for business
Google App Engine for Business (GAE) is a development and hosting platform for web applications. In some sense, it can be compared with an application server or more precisely with a cluster of application servers that offer similar services. GAE is a Cloud Computing technology that proposes to use Google's infrastructure to run applications that are scalable when the number of requests increases or when the need for storage space grows. Designing and testing a GAE application are all done on a local development platform that simulates both the services offered by GAE and the constraints that apply to a GAE app. Once the application has been tested locally, it can be uploaded on Google's servers using a simple command in the development tool. So far, only two languages are available: Python and Java and, by extension, any language that can be executed on a JVM like Groovy or Ruby. For the Java language, the development platform (SDK) is available as an Eclipse plugin. Overview of Google App Engine for Java
Google sites
Google Apps
Enterprise data SDC
Google App Engine for Business 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 Secure Data Connector (SDC) that makes it possible for GAE to access data in IS behind a firewall will be covered in Chapter 9, Advanced Integration.
JVM (Java Virtual Machine) is the virtual processor that executes the byte code compiled from the Java source code.
[ 116 ]
Chapter 6
Applications that were developed for GAE can integrate seamlessly with all the Google Apps (Doc, Gmail, or Calendar). Any such application can then be distributed on the Google Apps marketplace. By the end of 2010, GAE will operate with a 99.9% SLA. Centralized management of applications and security tools will also be provided. Pricing is on a pay-per-use basis and starts when a certain threshold is crossed. Currently, this limit is about 500 MB of storage space and 5 million pages viewed per month.
The Google App Engine administration console provides access to application settings, logs, and billing information
A web console for managing any application that runs under Google App Engine is available. Deploying new applications, adjusting their settings, or changing the version number is possible as well. Reading logs and navigating the Datastore are yet more features.
[ 117 ]
Extending the Platform
The deployment environment for GAE The main features of the GAE environment are listed as follows: •
Support for most dynamic page-creation technologies like JSP for Java and all Python libraries
•
Data storage in a non-relational database (Datastore) that is accessible in read or write mode through a set of APIs
•
Sorting operations on data and transactions are available.
•
Load balancing and automatic scaling
•
Using Google Apps accounts for authentication
•
Ability to launch asynchronous tasks or to queue them
•
All these services are available for both Java and Python
The sandbox
For security reasons, and also to decouple applications from physical servers, each GAE application runs in a secured environment called a "sandbox". From a conceptual point of view, this environment is quite similar to the execution context of a Java Applet within a browser, which prevents an app from accessing local physical resources, like the file system for instance. The application is seamlessly distributed on a network of servers that creates as many instances of the application as is necessary to match the load. This environment, however, induces a number of limitations that you should be aware of when designing an application that will run on GAE. Accessing a remote machine on the Internet, for instance, cannot be done directly. A dedicated service, the URL Fetch Service, should be used for that purpose. For a Java application, this simply amounts to encapsulating a remote call with the java.net network API. A GAE application can only access those files that were uploaded simultaneously with the application itself. For persistence of data, other services should be used (see the following), such as the cache service or the Datastore. There are other limitations regarding the processes. These should only be started by web requests, by "cronjobs", or queued jobs and their execution time should not exceed 30 seconds. Also, a process cannot start another process. A Java application cannot use the java.lang.Thread. API for this reason.
[ 118 ]
Chapter 6
The Java environment
The Java development kit for GAE is compatible with Java 5 or Java 6. The environment includes the Java Standard Edition Runtime Environment (JRE) 6. The sandbox restrictions that we mentioned in the last section are implemented using the standard mechanisms of the Java security infrastructure at the JVM level. When a process violates one of these restrictions, a java.lang.RuntimeException exception is raised. Only part of the Java Enterprise Edition API is available to build an application running on GAE. Accessing the various GAE services (see the following table) is through the usual APIs. Handling HTTP requests uses that standard Servlet API. The following table indicates which Java Enterprise Edition APIs are available on GAE: Name of the API
Availability
Usage in GAE
Java Servlet API 2.4
Available
Basic API for handling HTTP requests.
Java Data Objects (JDO 2.3)
Available
Is the standard means to interact with a database whether it is relational or not. The GAE implementation includes an access to the Datastore.
Java Persistence API (JPA 1.0)
Available but partial compatibility
Another way to interact with a relational database. The GAE implementation allows accessing the Datastore but with restrictions.
Java Server Faces (JSF Available 1.1 et 2.0) but requires adjusting settings
The standard presentation component framework in Java.
Java Server Pages (JSP Available et JSTL)
The standard tag libraries in Java for building dynamic applications.
Java Beans Activation Available Framework (JAF)
Allows inspection and manipulation of arbitrary data types.
Java Architecture for XML Binding (JAXB)
Available
A Java library that allows conversion of an XML document into a tree of Java objects and vice versa.
Java Mail
Available
Allows mail exchange in an application independently of the protocol used.
The status and usage of the different Java Enterprise Edition APIs on the GAE platform
Other Java APIs from the Enterprise Edition that are not available with GAE include: EJB, JAX-RPC, JAX-WS, JDBC, JCA, JMS, JNDI, or RMI. The reason behind this is that GAE security mechanisms already take care of these features or that these APIs are not compatible with them.
[ 119 ]
Extending the Platform
For the Java community, it is of interest to know that Google has recently partnered with VMware, the company that acquired SpringSource. Starting now, applications hosted on GAE will be able to use the Spring framework. Recall that, to this day, Spring remains an essential component in software architecture and is used in more than 70% of Java applications. The RAD tool for Spring, Roo, developed by WMware, now includes the Google Web Toolkit, a graphical component technology from Google. Google and VMware jointly developed test and performance tools that cover the whole stack of software architecture.
The GAE services
To achieve high levels of security and performance, GAE offers an array of services that, for the most part, just encapsulate the usual APIs. URL Fetch allows access to a web service or another application on a remote machine while using Google's high-performance infrastructure. Mail enables sending mail while benefiting from Google's infrastructure. Memcache is a high-availability cache mechanism for storing key-value pairs. This service proves most useful when accessing the Datastore in a non-transactional way. Image manipulation is a service that can manipulate JPEG and PNG images. Asynchronous tasks can be used to start processing independently of request handling. There are two methods. The "cronjobs" are tasks for which one defines a periodicity (once a day, once every hour). The tasks can be queued in a waiting list as the usual means to handle asynchronous tasks. A relational database (will be available by the end of 2010). An SSL service for secure access to an enterprise domain (will be available by the end of 2010).
RAD: Rapid Application Developement
[ 120 ]
Chapter 6
Meeting the constraints The Datastore
The Datastore is a distributed and transactional persistence mechanism, which has its own request engine. The distributed nature of the Datastore prescribes drastic limits on the structure of data that is not relational. The Datastore indeed has no equivalent for the traditional "join" between two tables, familiar in relational databases. Designing the persistence layer for an application running on GAE is substantially different from the usual practice with a relational model. Without going into too many details, let's mention here that any persistent entity is characterized by both a "kind" and a set of properties. A list of entities can be sorted according to one of its parameters and searches within the list can be performed. Respecting integrity constraints is the responsibility of application code. APIs like Java JDO and JPA contain tools that simplify their implementation. The Datastore uses optimistic concurrency management.
Quotas
Hosting of a GAE application is free; a Google account is all that is needed. Hosting remains free, provided storage space does not exceed 500 MB and that a quota of 5 million pages accessed per month is not exceeded. To go beyond these limits, it is possible to enable billing for hosting. Each Google Apps account can deploy at most 10 applications running on GAE.
A few examples of sites running on GAE
The Food Prints application offers the possibility to retrieve the nutritive value of products from a large number of brands. The Café Survey value can help to quickly create a poll and to collect associated data. The iFreeTools CRM is a customer relationship management system. The tFeeder application is an aggregator based on Tweeter that deals with news in the technology world.
[ 121 ]
Extending the Platform
Summary
This chapter discussed two different ways to extend the Google Apps Platform. On one hand there is Google Apps Marketplace where customers can purchase new products. On the other there is Google Apps Engine, which helps design and run application that will benefit from Google's datacenter infrastructure. However, in order to benefit from these high-scalability and high-availability features, a GAE application has to meet a certain number of constraints, among which is the need to use the Datastore, a non-relational persistence mechanism.
[ 122 ]
Part 3 Advanced Integration with the IS Managing a Google Apps Domain Federated Identity and SSO Advanced Integration Google "Workstation" Third-Party Extensions
Advanced Integration with the IS Google Apps, as we saw in Part 2, are at the core of Google's offer for communication and collaborative tools. However, in most cases, these basic services will not be enough and the need for closer integration with the existing IS data will remain. An important part of the integration certainly involves using an existing business directory for Gmail contacts. But, more generally, the integration process can go two ways and there are recurring issues that need to be addressed. First, there is the need for Google Apps to access existing enterprise data. Second, there is the need for existing applications to access data managed by Google Apps. In the first case, you could consider using a document repository based on Google Docs, for instance, or using a resource calendar based on Google Calendar. In the second case, you could consider integrating some Google Apps like Gmail or Google Calendar within an existing enterprise portal. Even more important is the integration of Google Apps in an existing security realm or an SSO domain. For each of these questions, there are solutions, provided either directly by Google or by its partners. The five chapters of this part of the book review the various aspects of these two categories of solutions.
In Chapter 7, Managing a Google Apps Domain, we start by reviewing the basics of the administration tasks for a Google Apps domain. A mastery of these tasks is a prerequisite to any form of advanced integration endeavor. Managing user accounts, creating groups, and granting appropriate rights are the main topics here. After reviewing the main concepts related to identity management and to authentication delegation, Chapter 8, Federated Identity and SSO presents the main tools that allow the integration of the Google Apps in an SSO domain. Chapter 9, Advanced Integration presents data integration with the Google Apps in two directions. The first deals with third-party applications, which need access to data managed by the Google Apps. Access here is through a set of specialized APIs. Conversely, the Secure Data Connector allows Google Apps users to access enterprise data even when these are behind a firewall. Google desktop technologies are discussed in Chapter 10, Google "Workstation". The specifics of the Google Chrome browser are presented, as well as the two operating systems proposed by Google: Android, which is already available on dozens of smartphones and Chrome OS, which is an innovative operating system, both light and fast and meets the needs specific to working online. Finally, Chapter 11, Third-party Extensions reviews four products that are representative of the integration solutions from Google's partners. There are office tools and workflow tools. They are all available on the Google Apps Marketplace.
Managing a Google Apps Domain We start by explaining how to sign up for a Google Apps subscription and then how to activate it. In the next section, we review the principal administration tasks. Managing user accounts is certainly the most important one. We describe the key settings of a Google Apps domain and various advanced settings like those related to integration within an SSO domain or to Google Analytics. The settings specific to applications are covered in the last section.
Subscribing to Google Apps Which version to choose?
Google Apps exists in three editions: The Standard Edition, the Premier Edition, and the Education Edition. Here is a short summary of the features available in each of the three versions: •
Standard Edition: This edition is free and is intended for those who will use Google Apps mostly for private and domestic purposes or for smaller, nonprofit organizations. It is limited to 50 users and does not include the Postini services (see Chapter 5, Security Tools). The Gmail inbox includes a contextual advertising zone that lists a number of commercial links.
•
Premier Edition: This version is for companies. It costs $50 per user for a one year subscription. It has a 99.9% SLA and includes the Postini services. The archiving service from Postini must be subscribed separately. There is no advertisement.
•
Education Edition: This is a free edition, intended for academics and schools, which has the same features as the Premier Edition.
Managing a Google Apps Domain
The first table in the introduction to Part 2 of this book contains more information on the costs and the list of services in each edition. Recall that it is perfectly possible to first subscribe to a Standard edition, to rate the quality of the services and then, later, upgrade to a Premier version.
Five steps to register for Google Apps
Here are the basic steps to register for a Google App account and then to activate the services. The activation of specific services was covered in Part 2 and in the last section of this chapter.
Registering for Google Apps
Registering for Google Apps begins with choosing the name of a domain. This is the name of the primary domain, which will be used by Gmail. Other domains may be added later, once the Google Apps have been activated. If, for instance, the domain name is my-company.com, the Gmail addresses will all take the form
[email protected].
Registering for Google Apps is done in three steps: 1. Choose a domain name 2. Provide contact information 3. Create the first user account.
During the registration process, it will be necessary to confirm that changing the DNS records is indeed possible, otherwise the Google Apps services won't be operational. Once the registration process is completed, the Google Apps administration console will look as shown in the following screenshot:
[ 128 ]
Chapter 7
The Google Apps admin console, once the registration process is complete. At this stage, the services are not yet operational.
Confirming Domain ownership
To prevent any abusive use of the Google Apps, domain name ownership must first be confirmed. The domain name should be registered with a registrar in case this has not yet been done.
Asking for domain ownership confirmation in the console
There are two methods to confirm domain ownership. Both use a private key provided in the Google Apps administration console: •
The first possibility is to publish an HTML file that contains the key, directly at the root of the domain
•
The second possibility is to change a CNAME record in the host's DNS page using the same key and pointing the record to google.com
Checking domain ownership using a temporary CNAME record, which contains a key provided in the console
[ 129 ]
Managing a Google Apps Domain
Managing user accounts
Before routing incoming mail to the Gmail servers, the administrator should create the user accounts that will match with the future recipients. There are actually several ways to do this (see the section dedicated to group and user creation that follows).
Creating the user accounts before redirecting mail
The exact procedure will depend on the situation: •
New accounts can be simply created from scratch (see paragraph 7.2 concerning the use of CSV files)
•
A complete migration can be performed starting with existing accounts (see Chapter 14, Performing the Migration)
•
A partial migration can be performed in order to set up a pilot project (see Chapter 13, The Pilot Project)
Changing the MX-records to activate Gmail
For incoming mail to be routed to Gmail's servers, it is necessary to modify the MX records in the DNS console of the host with which the domain is registered. The details of the procedure will vary slightly from one host to another. The procedure is described in detail on the configuration page that shows up when the link "activate email" is clicked in the dashboard (see the following screenshot):
Following the link "Activate email" in the dashboard opens a link with detailed instructions for MX records values
It is important to remember that an improper change of the MX records can have serious consequences when mail accounts preexist. Indeed, messages are simply lost in the case of an error. [ 130 ]
Chapter 7
This is the reason why the Google Apps console proposes using a temporary email address that is independent of the MX-records. It has the following form: <username>@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
