Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In my org today, we use the following:

  1. W2K8 R2 - Active Directory
  2. Google Apps for Enterprise
  3. Salesforce Enterprise version

Each of these has it's abilities for SSO connectivity. I would like to connect them, so my users will have a single password instead of 3 to remember ( I urge them to replace all 3 every month - they don't listen - I do).

What should be the correct procedure? easiest?

  • Google Apps support - SAML, Federated Login with OpenID and 3rd party OAuth. - I can use their google directory sync to sync my domain to the google service.
  • Salesforce support the following enter image description here

    • Where does the Active Directory fit in the picture?

My question is where does SF security fit here? Whom should be the delegate/federated entity? Should I look for a 3rd party? (I think that only adds to the complexity - or not?)

note: I am NOT looking for a step-by-step here. I can't figure the scheme of which entity will hold what position in the SSO authentication process.

share|improve this question
You want ADFS 2.0, which can "speak" SAML 2.0 for these webapps. Setting it up is not terribly easy... – Chris S Oct 31 '12 at 13:24

I would recommend using SAML to provide SSO to both Google Apps and These would be acting in the "service provider" role of the SAML federation model. Once Google Apps and are configured for this, users that try to access either one directly (e.g. via bookmarks or emailed URLs) will be redirected to an "identity provider". The IdP is responsible for interacting with the user to validate their identity. The IdP would be configured to use your Active Directory as the user repository - this is the only place where user passwords would actually need to be managed. The IdP would then send the user back to the SP with a SAML response that contains identity claims about the user. The SP verifies the authenticity of the response, then uses the claims to map the AD user to the appropriate Google Apps or account.

Incidentally, we use this exact model internally with our PortalGuard product as the IdP for both Google Apps and You could also use ADFS, OpenAM or Ping in this role, but PortalGuard provides other features such as two factor/stronger authentication, self-service password management and password synchronization.

The only other caveat here is that you need to have at least the Enterprise edition of to support SP-initiated SSO (where the user accesses SF first). Google Apps supports SP-initiated SSO just fine.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.