By Garret Grajek, CISSP
COO, MultiFactor Corp.
Google has offered enterprises a unique opportunity to reduce the IT cost via the offering of hosted applications, such as messaging, calendaring and document sharing. As with any hosted service, Google Apps introduces a new set of responsibilities associated with a secure establishment of identity to hosted applications.
Fortunately, Google has created a secure “trusted authentication” system via their support of SAML 2.0 for identity establishment. Google Apps has built-in ability to not only redirect the user from Google Apps to the resource holding the credentials (the identity provider) but to also trust the authentication via a cryptographically-strong model – the SAML 2.0 assertion. (See Diagram #1)
Enterprise Should Take Advantage of Google SAML 2.0 Authentication
The Google ability to accept a SAML 2.0 assertion means that enterprises can:
- Retain the identity credentials of their users
- Provide their own authentication methods
These are both very important concepts in todays regulated IT market. For regulatory measure such as Gramm-Leach-Bliley, PCI DSS and FFIEC, enterprises must not only be able to document that identities are securely retained and administrated – but often that the access to the resource is done is certifiable secure manner. This second regulatory function – is where MultiFactor SecureAuth can greatly help the enterprise.
SecureAuth® Secures Google Apps for the Enterprise
As stated, Google provides the ABILITY for enterprises to keep their own user credentials and to implement their own authentication – but the choice of the authentication tool – is up to the enterprise.
This makes the decision for the enterprise a little more complicated. Not only does the enterprise have to find an authentication solution that solves the issues resulting in Web Authentication, including:
- Key Logger
- DNS Attacks
The enterprise must also find a solution that works in Google’s SAML 2.0 authentication model – that is where the authentication solution:
- Can be exposed to Google Apps as a URL (See Diagram #2)
- Can create a SAML 2.0 Assertion for Google Apps to accept (See Diagram #1)
MultiFactor SecureAuth® for Google Apps is this solution.
- Is “Exposed” to Google Apps via a public URL
- Can create the session ticket needed, after authentication
- Connect to the enterprise native user store
This last item is key. Because SecureAuth® connects to the enterprise user store the enterprise has the ability to retain identities “in-house” – and thus put in all the necessary administrative tools and practices in place to meet the relevant regulations (PCI DSS, GLB, FFIEC, etc.) In short, the enterprise keeps the user’s data in place – under “lock and key” – as if the application was in-house.
This is truly the beauty of the federation model and how SecureAuth® integrates. Regulations are pretty much determining that enterprises not only maintain user accounts – but also put in extensive practices to insure their safe keeping. The application itself can be hosted at another site – as long as the enterprise can prove:
- The identity credential is securely stored
- The session for the authentication/authorization is secured
Because Google Apps has chosen to utilize SAML 2.0 for federation, the 2nd requirement is met. What is left to the enterprise is to insure that the authentication can create a secure SAML ticket and actually authenticates the user in secure manner. MultiFactor SecureAuth meets both of these requirements.
Diagram #3 – MultiFactor SecureAuth Integration into a SAML 2.0 environment. (click to enlarge)
SecureAuth® Enables Minimal Installation Cost
Another important component to the SecureAuth®/Google Apps solution is that the enterprise can achieve advanced functionality (SMS Text Messaging, Telephony OTPs and Certificate distribution) all without installing the infrastructure. This is because the server web plug-in that the enterprise deploys has fully functional and secure WSE 3.0 client stubs to MultiFactor’s webservices that provide these secure services. This saves an immense amount of cost on deploying and maintenance of these services. (See Diagram #4.)
It is important to note – that these web services are only needed during registration of a new browser to a user – subsequent authentications these services are not utilized. (See Diagram #3)
Diagram #4 – MultiFactor SecureAuth® WebServices (click to enlarge)--
Garret Grajek is the COO and a co-founder of MultiFactor Corporation. He is a certified security engineer who has deployed 100s of security solutions while working for RSA, IBM, Cisco and others.