First of all, hats off to Ping Identity for putting on a great forum for discussion.   And yes, it’s called the Cloud Identity Summit – but if you have any interest in:

• Federating Authentication
• Conducting host and|or SaaS SSO
• Provisioning Users
• Providing collaborative authorization
• Understanding the standards  and how they tie together (SAML, OAOTH, SPML, OpenID, WS-*)

This forum is worth it’s weight in gold.   The heavy hitters like Eric Sachs from Google and Vittorio Bertocci from Microsoft (Azure|WIF) were present.

Which is why the forum was such a perfect place for SecureAuth to dialogue its “Identity Enforcement Platform” – the only solution at the show that was able to:

• Pull the identity from the enterprise datastore (AD, LDAP, SQL, etc)
• Conduct either:
  • Secure Desktop SSO (Intranet)
  • Secure 2-Factor Authentication (Extranet)
• Pass the identity on to:
  • Hosted Web Apps (Microsoft, IBM, J2EE)
  • VPNs
  • SaaS applications  (SalesForce, Google Apps, Postini, etc)
• And provide:
  • SSO between resources
  • Policy based group authorization

SecureAuth – Identity Enforcement Platform

Figure #1: SecureAuth is an “Identity Enforcement Platform”, leveraging identities from the enterprise and enforce to 1) Internal Applications, 2) VPNs and 3) Cloud applications.

It really was fun.   Many people at the show knew SecureAuth as a multi-factor authentication solution – but where unaware of SecureAuth’s other capabilities.  (Which had existed since 2008, but was just a matter of messaging.)

Fun stuff.    And a great place to dialogue the solution.

SecureAuth’s, CTO,  Tom Stewart (photo #1, photo #2), presented to the entire audience at lunch – and, really knocked it out of the park.   Great preso (check out some of his fun images) and great reception to the message.  (Booth was deep for 2 hours after his great lunch overview)

Figure #2 – Tom Stewart details SecureAuth’s “Identity Enforcement Platform” to the              Cloud Identity Summit 2010 audience

All the best – and look forward to any direct conversations!

–
Garret Grajek, CTO of SecureAuth  Corporation

It was a good exercise.

It forced me to think why SecureAuth starting using SaaS, as part of the product since 2005.   That’s right, we at Secureauth not only believe in SaaS as something that SecureAuth can protect (Google, Salesforce, Azure, Postini) but has been an integral part of our product since 2005.

SecureAuth believe in SaaS, because:

• SaaS saves infrastructure support for:
  • Personnel
  • Network Infrastructure
  • Application Infrastructure

The SecureAuth model, is to enable secure SaaS deployments by connecting a SecureAuth authentication appiance on-premise and connecting to an enterprise’s native data store.   From there SecureAuth is able to utilize the native identities (for B2E, B2B and B2E) and enforce these identities for both on-premise web sites and SaaS applications.   (See Figure #1)

Figure #1 – SecureAuth is installed on-premise to conduct a secure 2-Factor SSO authentication to SaaS applications.

The SecureAuth architecture gives (4) distinct advantages to the SaaS utilizing enterprise:

1.   Utilizes On-Premise User Store

2.   Conducts On-Premise Authentication

3.   Enables Enterprise Integration (SSO)

4.   Facilitates Logging/Auditing

The benefits of these (4) aspects are as follows:

1.   On-Premise User Store:

• Single ID/Password
• No user credential syncing
• No user credential migraion

2.   On-Premise Authentication

• Enable enterprise to configure authentication per SaaS resource
• Can adjust to relevant guidelines  (FFIEC, HIPAA, NCUA, PCI DSS, etc)
• Not tied to SaaS vendor supported authentication solutions

3.  Enterprise Integration

• SSO into both SaaS and on-premise web applications
• Can also authenticate VPN solutions
• Desktop, internal SSO available as well

4.    Logging/Auditing

• SaaS authentication is audible with SecureAuth
• Tracks which users authenticated to which SaaS application and when
• Can be integrated to syslog, SIEM equipment

For these  (4) reasons, SecureAuth is the “right” way to do SaaS.  It enables an enterprise to securely deploy multiple SaaS based applications and integrate them into an enterprise infrastructure.

–
Garret Grajek, CTO of SecureAuth  Corporation

SecureAuth strong authentication platform enables SSO across SaaS, Web and VPN resources

—
Webinar:  SecureAuth – Cloud SSO in-a-snap, July 15th

—

Enterprises struggle with creating a common authentication experience across their disparate SaaS, Web and VPN resources.   This is mainly the fault of the authentication solutions – which up to now, where unable to abstract themselves from the application.    Most 2-factor authentication solutions require an enterprise to integrate cumbersome APIs.  (See figure #1, below)

Traditional Methods for Authentication Require Multiple Solutions

Figure #1 – Current Authentication Infrastructure, multiple data stores, multiple authentication types

SecureAuth is different.

SecureAuth is a stand-alone authentication appliance that integrates with both SaaS and web applications without APIs and extensive coding.   SecureAuth creates an SSO experience for end users by abstracting the authentication from the resource .   These resources can be a secure corporate network, a Microsoft, IBM, J2EE or a cloud applications such as Google Apps and Salesforce.com.    SecureAuth is a secure web application itself, secure sessions may be kept active for a specified time period, allowing  for strongly authenticated users to access multiple resources at once using a single secure session.

In addition, SecureAuth abstracts user data from an enterprise’ existing user datastore, multiple applications can be securely accessed with a single log-on, using common credentials.  SecureAuth is architected differently than typical authentication solutions. 

Specifically, SecureAuth is capable of passing more than a binary “go/no go” response to the protected resource.   User group data can be securely passed for authorization and provisioning purposes.

SecureAuth Solves Cross Resource (SaaS, Web, VPN) SSO Authentication

Figure #2 – SecureAuth allows a user (1) to obtain SSO to disparate resources.   These include VPNs (2), Microsoft ASP.NET applications (3), Oracle Applications (4), IBM WebSphere and other web applications (5), as well as SaaS applications including Google Apps (6)  and SalesForce.com(7)  and other SaaS applications (8).   All of these policies can be configured at the SecureAuth authentication appliance (9).   The user information can all be derived from a single user store  (AD,LDAP, SQL, etc) (10).

SecureAuth was designed to leverage a single, pre-existing datastore (AD, LDAP, SQL, etc)  of user information.  There is no synchronization of a proprietary database.  Instead, SecureAuth grants secure, 2 factor authentication based on data accessed real-time from the directory of record.  The enterprise administrator owns the user data and remains in full control of access to all resources.  End users have the ability to access any application which they have rights to from any client platform which is allowed under the enterprise’ security policy.
 
SecureAuth is configurable to allow for strong authentication into various types of applications.  By enabling multiple instances via a simple administrator’s interface, SecureAuth will pass several types of  authentication tokens, depending on the application.  Other solutions by contrast require applications to be modified to accept authentication or federation schemes.  SecureAuth uses standard authentication tokens to keep integration trivial by comparison.  

The end result:  access to any application, within the enterprise, or out in the cloud, is controlled by the enterprise and is protected by the strongest 2 factor authentication available.

–
Webinar:  SecureAuth – 2-Factor SSO Across Web and SaaS applications, July 15th
–
Garret Grajek, CTO of MultiFactor Corporation

• Secure Postini Access
• SSO from Google E-mail

Quick question:   How do you (or your users) access your spam filter?  I asked around the office and most just shrugged with that, “Nice question, Security boy – but I have a day job to attend to.”

Exactly – workers have day jobs and can be bothered with:

• Multiple log-ons
• Multiple URLs
• Multiple Authentication mechanism

SecureAuth provides the users the ability to:

• Use their AD credentials to log in  Postini
• Use the authentication from Google to log in to Postini
• Allow enterprises to use their portal page for the SSO links  (See figure #1)

Figure #1: SecureAuth enables enterprises to provide secure SSO between 1) Google E-mail and  2) Postini applications.

Once the user has executed a SecureAuth authentication to any resource, be it Google Apps, SalesForce, .NET, WebSphere or any other secureAuth resource, the user can then click an enteprise-hosted Postini link and obtained the Postini resource (See link #2)

Figure #2: Users, via SecureAuth are allowes secure SSO to Postini.

If that isn’t enough, SecureAuth allows the enterprise to create a whole set of different policies for the Positini admins.   Once again, the credentials are set off enterprise active directory.   SecureAuth allows the enterprise to configure the strength of authentication (for both users and admins) to include:

• X.509 v3 Certificates, SMS, Telephone, E-Mail, PIN, KBA and help desk

Once the admin is authenticated by SecureAuth the admin user is redirected to Postini with full admin access (see figure #3).

Figure #3 – SecureAuth can conduct a 2-Factor, SSO authentication for Postini admins based on the active directory (or other directory) based at the enterprise.

–
Webinar: Securing Google Apps with SecureAuth, June 10th
–
Garret Grajek, CTO of MultiFactor Corporation

—

After some extensive travel that did me everywhere from Google’s office in London, an Identity conference in Munich and the finally the Google I|O Show in San Francisco – something became obviously clear to me:

Enterprises should federate their applications, not their identities.

At the identity conference there were the standard hand-wringing conversations about the “trust” around letting a 3rd party own the identities.  And then there was the conversations around how to take those identities and leverage them to the relevant resources, both internal and external. Of course, what trumped all ideas/theories – was how to meet regulatory acceptance – when, the fact is, you as the enterprise, don’t actually own the identity.

Well, I have a simple answer:    Don’t.

Seriously.

• Don’t federate your identities
• Don’t push your identities to someone else
• Don’t “trust” someone else to host your identities
• Don’t synch your identities to some one else

So what’s the solution, then?

Federate your applications, not your identities.

That simple.  To then enteprise, this means:

• Keep the identities under your control
• No Authentication credential synching
• Don’t break auditor compliance
• Retain identity/authentication/logging control

The solution to this dilema, is SecureAuth – the only federation solution that installs as 2-Factor authentication appliance and provides:

• Integration from your Directory
• Federates the identity to SaaS applications like Google Apps and SalesForce

To then enteprise, this means:

• No Password Synching
• Local Authentication
• Local Logging
• Federated SSO to SaaS applications like Google and SalesForce

And the identities?

You already have the identities!  It’s your Active Directory!  Or your LDAP, or your MS-SQL, or your Oracle database. Why would you migrate those users?   To do so is expensive, fraught with complexities and, also, breaks most regulatory guidances.

SecureAuth Enables Enterprises to Federate Applications

Figure #1: SecureAuth allows Enterprises to retain identities and federate their applications

Please contact us, and well begin to solve end-user problems together.

———
And join us for a MultiFactor/Cloud Sherpas: “Secure Google Apps- AD-to-Google SSO”, Webinar, on June 10th, 2pm EDT.

Garret Grajek, CTO of MultiFactor Corporation

But the issues has been:

• How to do this and not impact users?
• How to leverage existing user information/accounts?

The solution to this dilema, is SecureAuth – the only solution that installs as an appliance and provides:

• Integration from your Active Directory
• SSO into Google

To then enteprise, this means:

• Seamless User Migration
• No Password Synching
• No Account Synching
• No dual account management

and…

• SSO into hosted web applications and Google Apps
• 2-Factor Authentication to hosted and SaaS Apps
• 2-Factor Password Reset
• 2-Factor User Management
• 2-Factor Help Desk Management

The enterprise can actually enjoy a simple, user authentication, provisioning and recovation of users via the SecureAuth/Google Solution than they can with a home grown system.

But this is only part of the advanatage.   Unhappy users can kill even the best of IT projects. This is where the SecureAuth solution shines.

SecureAuth is the only solution, capable of providing this unique, 2-prong solution to Google connectivity.

• Internal Users:     Simple, “Desktop-to-Google” SSO

• External Users:    Secure, 2-Factor, authentication

It is this dual authentication abilty that is unique to the SecureAuth solution.  Only SecureAuth has the ability to construct a different authentication experience, based on the internet location of the user.   It it important to note – that this solution is not only attractive to users – but infinitely mores secure than contrasting username/password solutions. (See Figure #1 – SecureAuth, Secure SSO Authentication)

Figure #1 – SecureAuth provides both simple “Desktop-to-Google” SSO for internal users, and secure 2-Factor SSO Authentication for external users.

Please contact us, and well begin to solve end-user problems together.

———
And join us for a MultiFactor/Grove Group: “Secure SSO – Desktop-to-Web-to-Cloud”, Webinar, on April 22nd, 10am PDT.

Garret Grajek, CTO of MultiFactor Corporation

So why should the end user have a “New” experience just because IT decided to save some sheckles on moving the application to an off-site hosting site. They shouldn’t. They don’t . And they don’t have to.

This is the beauty of the SecureAuth breakthrough.

Desktop -> Web -> Cloud SSO

When we as IT people say “SSO” to and end-user, the end-user thinks they just need to log in “once” and never again. Too many cloud vendors play the “shell game” and say, “oh we mean SSO means you just use the same directory – but you still have to log in again”.

SecureAuth is able to provide true SSO: “Desktop->Web->Cloud” SSO.

Really?
Really.

The SecureAuth solution:

• Can obtain the user’s identity from the desktop login
• Check appropriate security policies
• Provide a SSO experience, directly into hosted applications
  • SharePoint / OWA
  • ASP.NET
  • WebSphere
  • Other Web Apps
• And…
• Provide SSO experience, directly into SaaS based applications:
  • Google Apps
    • Google Sites
    • Google Docs
    • Google E-mail
  • Salesforce CRM
    • Salesforce CRM
    • Force.com
  • Other federated sites
    • SAML 1.1, SAML 2.0, OpenID

Most importantly, leveraging the current data store and doing it in a way where there is:

• No credential synching
• No password synching

 Image #1 - Secureauth provides “Desktop -> Web -> Cloud” SSO.

Fun stuff.  Let’s talk and do what, well, we are supposed to do in IT:
Solve end users problems.

Please contact us, and well begin to solve end-user problems together.

———
And join us for a MultiFactor/Grove Group:  “Secure SSO – Desktop-to-Web-to-Cloud”, Webinar, on April 22nd, 10am PDT.

Garret Grajek, CTO of MultiFactor Corporation

Been putting together a March 25th Health Care webinar with Kevin Peterson, the Sr. product manager for the Juniper SSL VPN. The emphasis is on SecureAuth’s flexibility to map its level of authentication: Certificate, SMS, Telephony, Username/Password to any Juniper Authentication realm.

Health Care has the need to deploy disparate IT resources to disparate resources (Web Apps, File Shares, Servers) to disparate user groups (Physicians, Clinicians, Insurers, Providers , Patients, etc). These different IT services (resources)for different group (roles), require different types of authentication for the different policies (realms).

This is exactly what SecureAuth provides, configurable authentication that maps to the Juniper 3R’s (resources, roles, realms).

At the same time I read Sebastian Rohr, of the Kuppinger Cole group, who SecureAuth has been working with, discussing the need for Variable Authentication Service Platforms. (We have been working with Sebastian a lot on SecureAuth authentication and its implementation to both Hosted apps (OWA, etc) and Cloud (Google Apps, Saleforce, etc) applications.

Talk about convergence.

VASP, or a Variable Authentication Service Platforms, defines what SecureAuth is.

SecureAuth is a flexible, authentication platform that can be configured to the resources and roles pertinent to the policies. The end state is a unique SecureAuth authentication realm, that maps to the designated resources and roles.

SecureAuth now ships with 25 of these Authentication Realms, that can map to 25 different distinct roles and resources . (See figure #1)

Image #1: SecureAuth will be shipping with 25 Authentication Realms that can be be configured to disparate roles and resources.

A SecureAuth Authentication Realm can be individually configured for roles:

• Separate directories, datastores (AD, ADAM, Novell eDir, IBM LDAP, SunOne, OpenLDAP)
• Separate groups (One or several)

And once the role is determined, the actual authentication can be configured, individually for authentication realm, these choices include:

• Registration Methods:

  • Telephony, SMS, E-Mail, KBA, PIN, HelpDesk

• Identity Transport Mechanisms:

  • X.509, SAML, Microsoft FBA, IBM LTPA, OpenID

• Configurable Credentials:

  • Expiration
  • Storage (Native or JRE)

• Identity Management:

  • Credential Revocation
  • User Password/Profile Management
  • Group Profile Management

HealthCare isn’t the only industry that needs to map the 3Rs, Realms, Roles, Resources, but certainly has been in the news the most lately, no? And that’s we chose to conduct this webinar this Thursday, March 25th 10am PST.

It’s good opportunity to discuss how a VASP (Variable Authentication Service Plaftorm), like SecureAuth, can be applied to solve Health Care remote access probems with Juniper SSL VPNs.

Of course, readers might have others issues to solve, and are encourage to conduct us directly at sales@multifa.com or me directly.

Thanks.

Garret Grajek, CTO of MultiFactor Corporation

If you didn’t make it to San Francisco for the RSA 2010 show – let me give you a little clue – it was all about the cloud. 

And that was good for SecureAuth.   Real Good.   We  at MultiFactor have been about the cloud since 2006.

Image #1   -  SecureAuth has always leveraged the cloud for advanced webservices, such as 1) Certificate Authorities, 2) SMS Text Messages  and 3) Telephony OTP

SecureAuth always recognized that the cloud was the right way to execute functionalities that were either:

• Too Cumbersome
• Too Difficult
• Or Too expensive

To manage in house and/or to maintain.

This is why the SecureAuth design, from day (1), leveraged the cloud.    SecureAuth is the only solution that has always been able to deliver native X.509v3 certificates to enterprises without the burden/expense/complexity of installing a certificate server.    SecureAuth expanded on this concept by enabling enterprises to utilize MultiFactor hosted:

• Telephony OTP Servers
• SMS Text Messaging OTP Servers

The leveraging of these MultiFactor hosted solutions make the SecurAuth solution the easiest bilateral (client/server) authentication solution to install and manage.   It virtually takes all the implementation and maintenance out of the installation process.

Compare the SecureAuth solution (image #1) to the same solution if an enterprise tries to host it themselves,  ( image #2).

For the comparable hosted solution, the enterprise needs to install:

• Certificate Authorities
• Certificate Storage Devices
• Certificate Revocation Devices
• Telephony Servers
• SMS Servers

Image #2)   This image shows the servers required to install a comparable solution on site.   (1)  Certificate Authorities,  (2) Certificate Stores,  (3) Certificate Revocation List, (4) SMS OTP Severs, (5) Telephony OTP Servers

If it was just about ease of use, SecureAuth wouldn’t be the new choice of secure environments.  What the attendees of the RSA conference recognized was this simple fact:

“The cloud doesn’t relieve an organization of federal or enterprise regulations, such as FFIEC, NCUA, PCI DSS, HIPPA or HITECH”.

So…

Where does it leave an organization?

It leaves the organization with the delima of:

• How do I leverage the cloud to save cost on maintenenace/complexity
• Maintain or achieve regulatory compliance

The SecureAuth solution is the ONLY solution that manages this difficult balancing act.   SecureAuth allows the enterprise to retain the user data, securely stored internally , conduct the authentication on premise – and leverage the cloud for the complex functionality.

Because SecureAuth has an appliance that can conduct the authentication on premise, the SecureAuth appliance can perform (3) relevant functions that are important to regulatory compliance: (See image #3)

The “Hybrid” SecureAuth “Cloud” solution provides, locally:
1.   Local Authentication to the enterprise’s native datastore
2.   Local Authentication workflow, modifiable to resource and user group
3.   Local Logging and Auditing

Image #3)   SecureAuth conducts the Authentication on-premise, meeting germaine regulatory compliance measures.   (1) Local Data Store,  (2) Authentication Workflow, (3) Logging/Auditing

All of these functions are configurable on the locally-resident SecureAuth server.   A feature not possible for solutions that do not provide an on-site component. 

More importantly, all of these functions make SecureAuth the Right Cloud Choice.

—————

To find out more, contact us at sales@multifa.com / +1 949.777.6959.   Resellers are encouraged to contact channels@multifa.com / +1. 949.777.6970.