When architecting Workspace ONE Access, it is important to understand its three
main components. First, we have the Service. The service component is the
heart of Workspace ONE Access it's the service who provides the user portal and
the administration web console the service is the identity provider
providing single sign-on access to applications some of the supported
authentication methods is handled by the service the service is available both as
a SaaS or hosted offering as well as for on-premises deployments next we have the
service URL this is the FQDN users enter into their web browser in order to
access the end user portal running on the service while technically not a
separate component it's a DNS entry the importance of the service URL makes me
want to treat it as a separate component the service URL is used as the SAML
issuer identifier and our third component the connector makes use of it
in order to be able to communicate with the service the connector is responsible
for connecting internal components to Workspace ONE Access it is the connector
who synchronizes users from local directories such as Active Directory or
LDAP directories the connector synchronizes the ThinApp repositories Citrix
and Horizon published applications and virtual desktop entitlements the
connector is also handling some of the authentication methods supported by
Workspace ONE Access let's take a closer look at each one of the three components
running on the Workspace ONE Access service is the end-user web portal this
is the application catalog where users can find and launch all of their
enterprise applications the service supports many different authentication
methods for example MobileSSO certificate-based authentication our MFA
solution called Verify device compliance and more
the admin web console is also hosted on the service as well as the user
directories we synchronize into Workspace ONE Access it is the service
who acts as the identity provider when federating to applications Workspace ONE
access service can act as both an SP or an IDP in a SAML Federation when adding
third-party identity providers for user authentication it is in this
service you establish the relationship and it is on the service where the
conditional access engine runs deciding who gets access to what and when
Workspace ONE Access service is offered as a SaaS or hosted offering as
well as an on-premises deployment the hosted offering is a true SaaS service
where VMware supports and operates the service component as with any true SaaS
offering we practice continuous development meaning new code is checked
in on a daily basis for the hosted service the domain names are fixed and
owned by VMware and there will be personally identifiable information
PII stored in the cloud what the information is stored is up to you as a
minimum we do require a unique user identifier but in order to support
Federation use cases more information is often needed such as email address first
and last name but if cloud hosted is not for you we do
offer the Workspace ONE Access service for on premises deployments as well for
on-premises you are responsible for maintaining the implementation and to
perform updates since you are hosting the service you can pick your own domain
and service URL and all PII are kept locally
the service URL is the URL or FQDN used to access the Workspace ONE Access
service for on-premises deployments we only support A record we do not support
cnames we also require reverse lookup records and it is important to have a
trusted certificate matching your service URL when deploying Workspace ONE
Access service on-premises make sure you start by specifying the service URL
before you configure too much and please don't forget to enable new and user
portal UI after changing the service URL
Workspace ONE Access service only supports one namespace one service URL
this means in SaaS hosted for example if you want to use your own FQDN or domain
name for user access you cannot just create a cname or your
own A record in DNS but what you can do is to make use of the HTTP 301 permanent
redirect message you deploy a network component that can generate 301 messages
and now your users can enter your custom URL and the web browser will be
automatically redirected to the correct service URL
since the connector is responsible for integrating internal resources to
Workspace ONE Access it is only logical to deploy it locally within your LAN the
connector only needs outbound port 443 traffic to the service for the
integration to work it is the job of the connector to synchronize user objects
from your Active Directory or LDAP user store into the access service the
connector integrates to your ThinApp repository Citrix or Horizon environment
and synchronizes these so they can be presented in the application catalog
Active Directory username and password as well as AD Kerberos radius and RSA
SecurID authentication methods are all handled by the connector
the connector is actually a collection of separate services that you can deploy
on separate machines or all on one and the same Windows server all the
connector services settings are stored and handled by the service making the
connectors stateless with that I've covered the three main components in a
Workspace ONE Access implementation the Workspace ONE Access service the service URL
and the connector.