SYN310: Deep dive into ShareFile Enterprise functionality

You can tweet about this session!

• Assuming basic knowledge of ShareFile
• Address common questions from PoC / Deployment
• Please hold questions to the end, as we’ve got quite a bit to cover

• Enterprise IT is in a difficult position
• Consumer devices and solutions evolving quickly
• Consumers are used to finding their own IT solutions
• Enterprise IT can’t keep doing what they’ve been doing an expect to close that gap
• Enterprise IT tasked with supporting 100’s of applications
• Intro: There are many business trends that impact IT. But consumerization is at the top of the
list.
• Key Points:
• Consumerization is being driven by the fact that consumer capabilities are surpassing
that of enterprise IT. The first source of this trend is the new generation of people
entering the workforce--bringing their personal workspaces, habits, and identity with
them. More sophisticated and very popular consumer devices are compounding the
trend. These devices have capabilities that far outreach enterprise IT computing
capabilities from even a few years ago – and they are easily available at low cost from
a variety of retailers.
• This proven by analyst like Gartner that have clearly stated that this is the one trend
that experts agree will drive the most change is the consumerization of IT. The
consensus among analysts is that this trend, which is already underway, will force
significant changes in businesses all over the world.
• Illustration/Anecdotes/Proof: We all see examples in the news these days, and you probably
see many more within your own company…

4 pillars of ShareFile ‐ Clients, Authentication, SaaS Application (Control Plane), Document Storage
Clients
• Native client experience across these platforms, while still maintaining consistency
• Clients ‐ OS X, Windows (XenApp / XenDesktop), Mobile clients with mobile editor, Outlook Plug‐in
Authentication
• Not technically part of ShareFile, but important to understand how users are authorized into ShareFile
• Potentially an on‐premises component to that as well
SaaS Application (Control Plane)
• ShareFile.com and ShareFile.eu
• Contains the business logic that drives SF as well as the webUI and reporting
• Deliberately a SaaS application to help you close the gap between the velocity of consumer and
enterprise IT services
• Speed at which we can evolve features

• Improves response time to address security issues
• 60% of our customers are not on the latest release of the SZC ‐ illustrates the difference between what
IT thinks they can deliver and what they really can
• With enterprise software the slower you update the more stable and reliable your system is, this
contrasts with consumer software which the faster you update it the more stable and better the user
experience is
Document Storage (StorageZone)
• Specifically separate from the rest of the architecture
• By splitting this out it allows us to address business logic separately from the data/documents being
stored
• By having it be a separate component it allows us to add features to the solution without impacting the
documents stored
• Cloud, on‐prem, hybrid
• Citrix‐managed, customer‐managed, access to existing repositories

Deploying the ShareFile mobile apps can take place in 3 ways:
• Via the public app store
• From an MDM solution ‐ ShareFile apps are available for packaging from other vendors (Airwatch,
Mobile Iron)
• And of course, as part of an MDX application set with XenMobile

• Now, if you’ve chosen to restrict app deployment to an administrator‐pushed model ‐ you want to
control which mobile devices are allowed to connect to ShareFile.
• By turning off the public app store, IT administrators are now responsible for deployment of the app,
and can apply rules and policies for distribution.
• This isn’t a feature exposed via the ShareFile UI, and needs to be requested through ShareFile
support
• User experience for this ‐ we don’t block access to the app store (obviously), but when this option
is available, and the user tries to log in from an app the downloaded themselves ‐ they are denied
access
As a security feature ‐ this is an account‐wide setting, and it is all or nothing.

• On windows and mac devices, we have similar controls to restrict unmanaged devices.
• Gives administrators the ability to selectively control which Windows / OSX devices are allowed to
synchronize content. Typically this is pushed out as part of your software deployment practices.
• This is somewhat more granular than the mobile device policies, in that the key could be pushed out to
an individual device.

• ShareFile is sold as both a standalone solution as well as bundled with XenMobile
• Features here are available regardless of how ShareFile is purchased / integrated into clients and
Application Tier
• Encryption ‐ Using AES 256 for the ShareFile application / requires PIN or Passcode to be set for the
app itself
• Poison pill ‐ allows administrators to set a threshold for access ‐ so that if a device doesn’t check in,
or if you lose a device after x days ‐ data is wipe
• Remote wipe ‐ only wipes the sharefile container, not a device wipe
• Disabling “open in” ‐ Built‐in Mobile editor, ShareFile can be a fully functional standalone tool ‐
preventing open‐in contains your data inside the ShareFile sandbox

If you’re deploying ShareFile as part of XenMobile ‐ the benefits of MDX are that we’re given significantly
more control
Clipboard ‐ copy and paste
Blocking Screen Capture
Disable Print
Require internal network

As a XenMobile administrator ‐ you have signifcantly more control over the restrictions around access to
ShareFile content on the device
• Sandboxed in ShareFile ‐ Data not allowed to leave the App
• Sandboxed in XenMobile ‐ Data can be exhcanged between ShareFile and other MDX applications
• Freely accessible ‐ Data can be exchanged between ShareFile and any app on the device
Of course, a XenMobile data wipe will destroy the entire managed container ‐ including the ShareFile
content.

• Sometimes the different ways we share content in ShareFile is misunderstood ‐ so we want to clarify
the 3 different ways you can share a file with someone else and the controls around that.

• In the most basic scenario, we have Anonymous sharing
• This is almost the email model of a file share
• I send you a link
• You can download or view the content ‐ if you don’t have a locally installed application, you can
view it online (with Microsoft Office Web Apps)
• The OWA viewer is going to have the most hi‐fidelity rendering of that document, because hey,
it’s Microsoft
• As the user ‐ I *can* get confirmation of downloads ‐ as administrator ‐ I can track IP address of the
recipients, timestamps, etc.
• Users and administrators can also expire links after they are sent

• Moving on ‐ I can send file anonymously, but with Request Contact Info enabled
• This is the most common way *I* send files ‐ and while it is still an anonymous download, key pieces
of information are requested from the recipient ‐ and in 95% of the cases, I get valid information
back.
• People often ask “but can’t you just fill that out with nonsense?” ‐ of course ‐ but from real world use
of the product, almost everyone puts real information into these fields
• This information is auditable ‐ and we’ll track name, email addr, timestamp, IP. So you can tell if the
link has been sent on to more than your intended recipients, and of course you can always retract
links you’ve sent.

• The most secure method of sharing with ShareFile is Requiring a Client login.
• In this model, I send you a link
• As the recipient, you get an email from ShareFile asking you to activate your client account and
choose a password
• After setting the password you can download or view the file
• Subsequent shared documents will require the user to login as a client using their password prior to
being taken to the download page

Additional controls around sharing which can be defined account‐wide:
• If you NEVER want your users to share documents anonymously ‐ ShareFile can be configured to
require client logins for ALL links shared
• Once you’ve gone to that step ‐ required client logins for sharing ‐ Blacklisting or whitelisting can be
configured to only allow your users to share content with specific external parties. For instance, you
could use blacklist to block out sharing to competitor domains ‐ or whitelist to enabling sharing with
your suppliers. This is also an all‐or‐nothing configuration.
• To enhance security for your clients ‐ we have 2‐step verification with SMS so that your users can opt‐in
to provide an additional layer of security for their logins.

• Enterprises want to use Active Directory.  They don’t want to have to have another set of passwords to
manage.   You’ve heard us talk about Employees and Clients ‐ Employees are licensed users, who are
entitled to use all the features of ShareFile ‐ and then we have “clients,” users external to your
organization who have been granted access to files.  Provisioning is specifically about setting up those
accounts for Employee users, and utilizing your AD infrastructure to populate your user set.

• Provisioning is the process of bringing your AD user accounts into sharefile.
ShareFile creates an ‘employee record’ which contains firstname, lastname, and email address based off
the information stored in your AD. Of course, we can also gather group data for bulk management of
access ‐ you can take your existing AD groups and their memberships, and use them effectively within
ShareFile.
No additional AD attributes are shared ‐ the actual provisoining process is only capturing a very speicfic
subset of data ‐ there is no impact on your existing AD infrastructure, no extention of AD, etc.

• Provisoining can take place 1 of 3 ways. We’re really only focusing on one in this session.
• First ‐ Provisioning can take place manually, entering it into our admin console or importing to ShareFile
via CSV file
• XenMobile App Control is another option ‐ which gives you complete management of user accounts
from the XenMobile admin interface
• But our focus in this section ‐ will be via the User Management Tool, which gives you the most
flexibility for user configuration, and is constantly updated to take advantage of new ShareFile
functionality.

• The user management tool is a lightweight windows application run on your local network by one of
your ShareFile account administrators.
• The tool needs no special permissions to access your active directory ‐ and will process a set of rules
you define:
• Provision Users
• Create Groups
• Update group membership
• Disabling user access
22

• Rules to provision employee accounts contain configuration options
• Each rule can have different options
• Options include: StorageZone, Quotas, and ShareFile permissions (create root folders, manage clients,
etc)
• Rules can be run on‐demand from the User Management Tool console or can be run on a scheduled
basis via the Windows Scheduler, we expect rules will be scheduled after the initial PoC
23

• Once employee accounts have been created within your ShareFile account

Now that we have taken a deeper look at user provisioning, let’s take a look at the authentication
methods that are available.
• ShareFile Managed – allows the user to login using an email address and password that are stored in
the ShareFile application tier ‐ this is the quickest way to get up and running in a proof of concept, but
we expect that most enterprises will want to integrate with their existing AD.
• Customer ‐Managed IDP – solutions such as ADFS, PingFederate, SiteMinder, Okta ‐ where we can
support all the common authentication methods: Forms, Basic, and Windows Integrated. These are
the supported solutions ‐ we conform to the Saml 2.0 standard, however as with most standards,
we’ve found significant variance between vendors.
• XenMobile ‐ The XenMobile App Controller is a SAML 2.0 provider ‐ and if you are deploying ShareFile
as part of a XenMobile deployment, this is the best option. In this configuration, no additional IdP is
required, and XenMobile provides everything you need.
• Note: All users are configured with a password in the ShareFile control plane, but there is an option to
block user logins with password when you configure SAML.
25

• So why do we use SAML?
• The problem that SAML resolves is trust.  ShareFile and its applications are not, and should not be
treated as, trusted entities inside your domain.  Similarly, we at ShareFile don't want to assume
management and security of your Active Directory username and password.
• Sometimes people ask us ‐ why don't you just take my credentials, and perform some sort of secure
tunnel back to my Active Directory to validate my password?  The short answer here is that you should
never give your AD username and password to a 3rd party.  But you knew that.  There's a better model
for managing this ‐ SAML is an industry standard for maintaining trusts specifically for the purpose of
validating credentials.
• In this model, by configuring a SAML server in your enterprise, you create that 3rd party which
ShareFile can interface with.
• Through your configuration, your Active Directory Trusts the Identity Provider.  ShareFile trusts the
Identity Provider.  Therefore ‐ if the IDP validates your credentials for us, we can treat that as a reliable
source.

• There are 3 components to the system. The Service Provider, in this case ShareFile.com ‐ we are the
service provider, which is outside of your environment.
<click>
• In the process of authenticating to the service provider, the user provides his username and password
to the IDP.
<click>
• If the authentication was successful, the IDP provides a signed claim back to the user ‐ in our case, the
claim contains a name ID in the form of an email address.
<click>
• The user then passes that claim (signed by the IDP) back to ShareFile. ShareFile trusts the signed claim,
and uses the email address supplied to tie this back to a ShareFile employee user.

• Client requests ShareFile SSO login URL
• Client discovers IDP
• Client redirected to IDP
• Client requests IDP URL
• IDP authenticates the user
• User is redirected to the ACS URL with the SAML response
• User request ACS URL and presents the SAML token
• ACS validates the SAML token and generates an OAuth token for client access
• ShareFile client provides OAuth token as part of https requests to ShareFile API server
• OAuth, that’s something new we haven’t talked about

• We’ve described the process of authentication between an IdP and SP so why do we use OAuth?
• An OAuth token is a long‐life authorication that allows us to authorize the client without re‐prompting
for authentication
• This is especially important for the Sync clients that need to constantly be checking for new document
updates when you are away from your computer
• OAuth is an industry standard for long‐lived authorization requests and prevents us from having to
store credentials on a machine
• OAuth tokens can be configured to automatically expire NEVER, or every 1,7,30 days. They can also be
manually revoked
• When an OAuth token expires or is revoked ShareFile requires the user to reauthenticate to the
Identity Provider
• Disabling a ShareFile employee account immediately revokes all of the OAuth tokens associated to
their account

• Recapping ShareFile authentication with our Architecture
• ShareFile clients talk to the IDP, we get a claim back

• StorageZone Connectors (which we haven’t talked about yet) are handled differently because in this
case we are authenticating to a resource that exists on your network.
• Since we don’t have those credentials we prompt the user for their Active Directory credentials when
accessing StorageZone Connectors. The username and password are transferred over a HTTPS
connection only to an on‐prem Customer‐Managed StorageZone Controller.
• The StorageZone Controller uses those credentials to impersonate the user when accessing the
resources on the network

• Storage is a key part of the ShareFile architecture, and we have a number of different options to
discuss.

• With StorageZones, we can host “ShareFile Data” in either Citrix‐Managed, or Customer‐Managed
repositories.  This can be cloud based, either in Amazon or Azure, or on‐premises in your own
datacenter.  Based on our flexible architecture, you can mix and match these types in your account, for
instance allowing one group of users to use cheaper cloud storage, while storing another set of users’
sensitive data in an on‐prem Zone.
• Additionally – we offer Connectors – which gives access to existing data types.  It is important to
remember that Connectors content does not include the full sync and share experience ‐ and instead it
is focused on bringing a single access point to your users.

• If you choose a Citrix‐Managed Zone for your account, that is fully managed by ShareFile.  That means
you have the benefits of our data reliability with either Amazon or Azure, and our operations team
focused on keeping the system up and running at all times.  This is the traditional SaaS model that
ShareFile was built on, and has been evolving since its beginnings.
• In this model, ShareFile runs the “StorageZone Controllers” and hosts them in the geographic region
most convenient for your cloud storage.
• Of course, all our data is encrypted in transit and at rest with AES‐256 bit encryption.
• There are additional benefits – Citrix‐Managed Zones are the most fully featured option we have, and
include functionality like FTP and AV scanning that again, is managed entirely by our team.  This takes a
lot of pressure off your administrators and makes for a system that can be set up very quickly – if you
requested an account right now, it could be ready to go within the hour.

We also offer customer‐managed StorageZones.  Typically our customers choose this model for one of
two reasons:
• Performance – By physically locating your data repository near your users, you can ensure a fast
connection to data.
• Compliance – For data sovereignty regulations or other compliance needs, a customer‐managed
Zone keeps file contents under your control at all times
Our on‐prem solution is very straightforward – called the StorageZone Controller, it is a web service that
runs on a server inside your datacenter.  Because it is really a data pump – it can scale up or out; of
course we recommend a minimum deployment to be a load balanced pair and suggest that you assess
capacity in your environment and add capacity as needed.
In this model you hold the encryption keys, and you hold the data.   The only information that passes
through ShareFile servers is file metadata – filenames, foldernames, and ACLs – but never the contents
of your sensitive documents.

• Talking a bit about our architecture, it is important to understand the distinction between what we call
file data, and file metadata.  In native ShareFile storage, we save every revision of a file you make as a
new object – and reference that object with a UUID.  If you were to look into one of our on‐prem (or
even cloud) repositories, you’d see a directory listing much like this – with a different UUID for every
file you upload.
• This is part of our “object store” heritage and frankly we believe it is the model more and more of your
data will follow over the next 5‐10 years.  The simplicity of an object store is that it decouples the
mundane task of storing files from the useful stuff – the actual consumption and distribution of those
bits.  That’s very important, because it means that we can define a very simple model for storing your
data – and leave it intact for years and years – while continuously adding new functionality.  This is very
different from, say, an NTFS share – where the directory structure itself contains both file information
(such as name) and also access rights and permissions.
• By using object stores and having this “split” between where we store your file contents and your file
metadata – we gain a tremendous amount of flexibility and future‐proofing.  The fact that we use the
same model anywhere you store ShareFile data allows us to mix‐and‐match, giving you as the
administrator many options for where your files live.

• StorageZone Connectors, on the other hand – are all about mobilizing existing data, either from your
datacenter or from other cloud services.
• On‐prem, we have fully functional solutions for read/write access to Network File Shares, as well as
check‐in/out access to SharePoint 2010 and 2013.   This gives your users a single place to go when they
want to access data – whether it is content that has been on your corporate R: drive for the last 10
years, or a document someone just edited on our ipad app.   To get to your on‐prem environment, we
use that same StorageZone Controller – so there is only one point of entry on your network and a
simple service to maintain.  For Connectors, we always impersonate the user accessing content – so all
of your existing permissions, auditing information, etc are still valid.
• We’re putting a lot of effort into connectors, and you’ll see continued evolution here as well as new
document repository sources being added by Citrix and our Partners.  We’ve recently published our
Connectors SDK, and we’re getting great interest in that as a way to take what have traditionally been
on‐prem content management systems and quickly making them available on mobile devices.

• In summary, when you’re talking about ShareFile and the content it can serve up – these are the
important concepts.  ShareFile Data – fully featured, sync and share, versioning, retention policies, all
of the benefits that ShareFile can get you.  This can live in the cloud or on‐prem, and you can choose to
manage that yourself or take a fully hands‐off approach.
• Connectors, on the other hand – limited to the permissions and functionality their original back ends
supported – so that’s read/write, check‐in/out.  In many cases those repositories have been in use for
years, or even decades – we don’t want to re‐architect the security on all that data you’ve already got.
So we’ll honor all the existing permissions, and appear to those sources as if the user were connecting
natively on the desktop.  This is a great feature and brings these documents to ios and Android quickly
and easily, without a lot of new infrastructure and with zero messy conversion of data.

SYN310: Deep dive into ShareFile Enterprise functionality

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a SYN310: Deep dive into ShareFile Enterprise functionality

Semelhante a SYN310: Deep dive into ShareFile Enterprise functionality (20)

Mais de Citrix

Mais de Citrix (20)

Último

Último (20)

SYN310: Deep dive into ShareFile Enterprise functionality