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 a