Office 365 is Microsoft’s cloud-based Office solution.
This article describes briefly how Swivel can be used to protect access to Office 365.
This is a high-level, preliminary specification; more detail will be added to the Swivel Secure Knowledge Base (kb.swivelsecure.com) in the near future.
Authentication for Office 365
Office 365 uses by default ADFS for authentication. ADFS is Active Directory Federation Services. Specifically, an ADFS Proxy would normally be used for this. In effect this allows users to perform an Active Directory type of authentication over the internet.
The user goes to their domain within Office 365 cloud. They are redirected to the ADFS proxy on their own premises to authenticate. The ADFS proxy is basically an ASP.NET application running on IIS that presents the user with a login page. The ADFS Proxy collects the credentials and submits them to the Domain Controller for verification.
If they are correct, the ADFS proxy issues the users with a “secure token” and they are redirected back to Office 365. Office 365 validates this token and issues the user with a Session Cookie to allow them access to the web application.
Using Swivel with Office 365
As Office 365 is a cloud application Swivel cannot be deployed directly to protect access. However, what can be achieved is to introduce the requirement to complete a Swivel authentication before the user is issued with a secure token.
To do this a Swivel filter is installed on the ADFS proxy (actually an http-module).
This time when a user reaches the ADFS proxy the, the ADFS proxy requests three credentials: username, password and Swivel one-time code.
The AD credentials are submitted to the ADFS proxy.
The Swivel filter is activated after this step. The filter submits the username and one-time code for verification. If these credentials are valid the issuing of the secure token and the redirect to Office 365 continue as normal.
If the Swivel credentials are incorrect the user is redirected back to the login page to re-attempt authentication.