dotCMS / core

Headless/Hybrid Content Management System for Enterprises
http://dotcms.com
Other
845 stars 465 forks source link

Salesforce Plugin #1644

Closed jtesser closed 11 years ago

jtesser commented 11 years ago
  1. Both Front End and Back End
  2. For Permissions in Salesforce there is a field that will contain Role Keys.
  3. Email based for login
  4. Add config to remove the ability to change or send password
  5. For logging ip | user id | timestamp | failed/success
jtesser commented 11 years ago

Dean Jose would be the guy to help us doc and get this ready for QA

joseorsini commented 11 years ago

This plugin can set connections to a Salesforce Server, retrieve roles keys stored on a field and sync the roles for the logged-in user. This is made by using OAuth 2.0 User-Password flow as authorization method, where Salesforce assigns an access token to the current user session. This access token is required for getting information from Salesforce server.

Please see for more info https://help.salesforce.com/help/doc/en/remoteaccess_oauth_username_password_flow.htm

This plugin works for frontend and backend login. Also, it overrides /html/portal/login.jsp file with a custom one that hides the "Forgot Password" link.

Notes:

1) Frontend/Backend login must be set to email address.

2) SSL for Tomcat must be enabled. OAuth 2.0 works only with https connections.

Please see for more info http://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html

3) Salesforce integration works the same way than CAS/LDAP integration. A dummy password is saved in our database, since auth is handled directly in Salesforce. There is no way to pull the Salesforce password for any user. Also our "Forgot Password" feature is disabled so in case an user can't login, it's up to Salesforce admins to handle this tipe of issue. Additionaly, a Salesforce user must be created for binding dotCMS with Salesforce. To make a successfull binding, we require from this user:

a) Email. b) Password. c) API Security Token.

Please see this wiki for more info about how it works

https://help.salesforce.com/help/doc/en/remoteaccess_oauth_username_password_flow.htm

4) Salesforce REST API works with Callback URLs. In order to set a redirect after login in Salesforce, we need to add at least two (2) Remote Access in Salesforce, that will handle both frontend (/dotCMS/login) and backend (/admin or /c) login.

For creating a Remote Access in Salesforce, please take a look at this wiki http://wiki.developerforce.com/page/Getting_Started_with_the_Force.com_REST_API

Each Remote Access will generate a Client Id and Client Secret codes. These codes are required and it must be set in src-conf/dotmarketing-ext.properties file (please see item 4 of this doc). Also, the Callback URLs are set as redirect urls for frontend and backend in the same properties file.

5) Data retrieved from Salesforce is in JSON format. Although the output can be sent from Salesforce in XML, the default format is JSON and the code is built to handle only JSON objects sent from Salesforce.

6) In src-conf/dotmarketing-ext.properties file, this variable must be set to true:

SALESFORCE_LOGIN_FILTER_ON=true

The Dynamic content path variable must be set to the actual dotsecure folder.

DYNAMIC_CONTENT_PATH=dotCMS/dotsecure

Also these variables are required

SALESFORCE URL FOR REQUESTING ACCESS TOKEN

salesforce_token_request_url=https://test.salesforce.com/services/oauth2/token

salesforce_redirect_uri_backend=https://localhost:8443/admin

salesforce_redirect_uri_frontend=https://localhost:8443/dotCMS/login

salesforce_environment=https://test.salesforce.com

salesforce_search_user_url=https://cs7.salesforce.com/services/data/v26.0/sobjects/User/

SALESFORCE VARIABLES - REQUIRED FOR USER-PASSWORD FLOW AUTH AND ACCESS TOKEN RETRIEVAL

salesforce_grant_type=password

salesforce_client_id_backend=xxxxxxxxxx

salesforce_client_secret_backend=xxxxxxxxxx

salesforce_client_id_frontend=xxxxxxxxxx

salesforce_client_secret_frontend=xxxxxxxxxx

salesforce_username=email@domain.org

salesforce_password=xxxxxx

salesforce_api_security_token=xxxxxxxxxx

EXPECTED RETURN FORMAT

salesforce_return_format=json

URL TO SEARCH ON SALESFORCE (MUST INCLUDE API VERSION)

salesforce_search_url=/services/data/v26.0/search

OBJECT TO SEARCH ON SALESFORCE. MUST CONTAIN ONE OF THESE VALUES: CONTACT, USER, ACCOUNT

salesforce_search_object=USER

USER FIELDS TO SEARCH FOR ACCOUNT INFORMATION. PLEASE DO NOT CHANGE THIS VALUE

salesforce_search_object_fields=FirstName,LastName,Email,ContactId

ROLE FIELD TO MATCH FOR ROLES SYNC. THIS FIELD MUST EXIST ON THE PREVIOUS SEARCH OBJECT

salesforce_search_object_role_field=AccessRights__c

SAVE LOG MESSAGES ON DOTCMS-USERACTIVITY LOG

save_log_info_useractivity_log=true

SAVE LOG MESSAGES ON DOTCMS LOG

save_log_info_dotcms_log=true

7) This filter and its filter mappings are required in dotCMS/WEB-INF/web.xml file

8) Salesforce roles must be created by a dotCMS Admin on the Roles, Tabs & Tools Portlet. Both role name and key should match the Custom Field values on Salesforce. Also, for avoiding issues after login, we recommend to assign at least one tab/permission to these Salesforce Roles.

9) All Salesforce auth activity is stored in tomcat/logs/userActivity.log file.

wezell commented 11 years ago

A couple of things -

1) we should not use config variables for things that won't change, for example:

#salesforce_search_object_fields=FirstName,LastName,Email,ContactId

or

#salesforce_return_format=json

If we are not going to change it or the code will not work with a different config, do not make it configurable. If you feel strongly that it should be configurable see #2 below.

2) Intelligent Defaults Whenever calling the Config.java to get a config variable, make sure to set the correct default value so configs that do not have that variable will still work - or we can just exclude it from the standard config.

Every Config.get can take a second parameter that will be returned as the default if the property is not found. We do not want to fill up our dotmarketing-config.properties with config variables that only apply to a tiny percentage of our users.

So, for example, in the login.jsp, we do a:

Boolean.valueOf(Config.getStringProperty("SALESFORCE_LOGIN_FILTER_ON"));

We should do a :

Config.getBooleanProperty("SALESFORCE_LOGIN_FILTER_ON", false);
jtesser commented 11 years ago

I will fix this on master.

Thanks, Jason S. Tesser Director, Support Services dotCMS, Inc. T: 305.858.1422 x7003 http://twitter.com/dotCMS www.dotcms.com

On Fri, Feb 1, 2013 at 3:08 PM, Will Ezell notifications@github.com wrote:

A couple of things -

1) we should not use config variables for things that won't change, for example:

or

``` #salesforce_return_format=json If we are not going to change it or the code will not work with a different config, do not make it configurable. If you feel strongly that it should be configurable see #2 below.

2) Intelligent Defaults Whenever calling the Config.java to get a config variable, make sure to set the correct default value so configs that do not have that variable will still work - or we can just exclude it from the standard config.

Every Config.get can take a second parameter that will be returned as the default if the property is not found. We do not want to fill up our dotmarketing-config.properties with config variables that only apply to a tiny percentage of our users.

So, for example, in the login.jsp, we do a: Boolean.valueOf(Config.getStringProperty("SALESFORCE_LOGIN_FILTER_ON"));

We should do a : Config.getBooleanProperty("SALESFORCE_LOGIN_FILTER_ON", false);

— Reply to this email directly or view it on GitHubhttps://github.com/dotCMS/dotCMS/issues/1644#issuecomment-13011680.

weedenwright commented 11 years ago

I had a question about this plugin. At some point, our group will be integrating with Salesforce, but only in that we will be retrieving content from salesforce using web services. We have already built 'proof-of-concept' that pulls content using the services they have made available.

We will not need to use their users/passwords/etc to log in, which sounds like what this plugin does (similar to dotCMS ability to integrate with LDAP). Am I correct in assuming that this plugin might be overkill? Could we reuse pieces of this plugin?

dotcmsCodeReview commented 11 years ago

primarily this is for authentication and authorization. There are examples in this plugin to connect to sales for but it is not for what you are intending to do

weedenwright commented 11 years ago

Great. Thanks for the clarification!