The client applies for connectivity to the controller by presenting its unique cryptographic signature to the controller. The controller has a finite list of users who are trusted and authorized and devices that are registered. The controller looks up the client making the request for connection against its white list. If that device isn't on the list, the controller just drops the packet and no connection is made. If the device is on the list and the controller sees its single packet authorization (SPA), then a mutual TLS connection is established and a handshake allows the device and the controller to exchange certificates.
Next the user is authenticated, typically through SAML, leveraging the identity provider (IdP) and the backend identity management system of the enterprise. The controller does a redirect to the client, tells it to go to a particular IdP, the IdP connects to an IAM like Active Directory and goes through the authentication process. If that's successful, it provides a SAML assertion that the client presents to the controller. The controller now knows it's dealing with a properly authorized user, then determines if the authorized device is associated with the authorized user. Once that's done, the controller enables a direct connection between the user and the desired service.
Despite all those steps, the user still can't penetrate the application's perimeter until the gateway is told to anticipate the user's connection and then confirms that connection through unique signatures. There is a further handshake to create a mutual TLS connection, PrecisionAccess checks a few more parameters in the background, and then the application flow can begin. It sounds like very detailed and complex but it takes only a few seconds and the user is completely unaware of all the mechanisms used to authenticate him and his device.
The end result is that a bad guy cannot circumvent this whole process by simply stealing someone's credentials or device, or hijacking a connection by placing a man in the middle of the connection. A typical use for Software Defined Perimeter is preventing unauthorized access to applications through phishing, a top security concern in most organizations. To access a Software Defined Perimeter-protected application, the bad guy needs not only a user's password but also his authorized device.
Another use case is to share an application with people in an ecosystem—employees, contractors, consultants, supply chain partners, etc. Rather than providing outsiders access to the broader network, a company can limit access to just a specific application. They would have no visibility to anything else within the greater infrastructure.
Yet another use case is to enable BYOD. A company can provide access to certain applications – and nothing else – via workers' personally owned devices. This way the company doesn't have to manage the entire device. It simply installs a small piece of software on the worker's device and the rest is all done in software.
Sign up for CIO Asia eNewsletters.