For a while you’ve been able to install the #AWESOME timeline Lightning Web Component from Github (https://github.com/deejay-hub/timeline-lwc) into any Salesforce org using CLI tools or similar. Besides being an awesome example how just how nice components you can build with Salesforce it also serves as nice addition to any org to provide nice visualizations.
Today I needed to use the JWT flow to get an access token from Salesforce to use the Salesforce API in a server to server scenario. To do that you need a private key (usually in PEM format) for the client and the corresponding public key in a keystore on the Salesforce side. Being lazy I simply generated a public / private key pair in Salesforce with an exportable private key and exported the keystore.
Since Salesforce exports the keystore in Java Keystore Format (JKS) I need to work with the Java keytool and openssl to export the private key. Below are the steps. The landing_site_pk alias below is the same of the private key entry in the keystore and the API name of the keystore in Salesforce and Passw0rd is the password specified when exporting the keystore. Adjust as needed.
Playing around with Salesforce Communities I accidentally removed my own profile from the Members of the Community. This in effect locked me out of administering the Community in that I couldn’t access the Builder or the Workspaces. Bummer! What to do? Now this was a test environment and I was the only user in the org so not exactly critical but I wanted to remember the way I got back in.
As I had full administrator rights to the org I could use the NetworkMemberGroup object to add myself (or rather the Profile I was mapped to) back into the Community. Now this cannot be done from Apex so it has to be done using the REST API, Data Loader or similar. I opted for the REST API approach.
To do this simply POST to the object as you would any other object passing in the networkId (the ID of the Community) and the parentId (the ID of the Profile or Permission Set to grant access).
POST https://mydomain.my.salesforce.com/services/data/v49.0/sobjects/NetworkMemberGroup Content-Type: application/json Content-Length: <length> Authorization: Bearer <access_token>
For a customer I was looking into Single-Sign-On (SSO) between multiple Salesforce Communities using a custom domain for each. Consider a customer with two communities (Community 1 at comm1.example.com and Community 2 at comm2.example.com) – these could be different customer communities, a customer community and a partner community etc. The issue we encountered was that when using custom domains (i.e. comm1.example.com and comm2.example.com) the built in session ID cookie support will not suffice as the cookie will be bound to the exact domain. This means the cookie is not sent along when accessing the second community and hence no SSO.
Now the solution to all this is using SAML with is baked into the Salesforce platform and included in the license. There is a bit more stuff to configure with SAML but once set up you get SSO for non-Salesforce Community properties as well such as a property on Heroku as well.
All in all I think it’s worth the additional configuration.
Before I list what I configured let me say that it may feel a bit convoluted as the Salesforce org is both the Identity Provider (IdP) and the Service Provider (SP) in SAML-speak. Usually Salesforce is either the one or the other but but not both.
Please note: Below I assume a certain level of knowledge about Salesforce Communities around controlling access to communities using Profiles, activating Communities and mapping to custom domains. All is well documented in the documentation but understand you cannot simply do the below steps and be done…
What I ended up configuring was the following:
A community (“SSO”) used for Single-Sign-On and self-service (password reset etc.) where I style and brand the SSO experience at sso.example.com. The community has a CA signed SSL certificate and a custom domain setup via the Domains setup.
A community (“Community 1”) for customers at comm1.example.com. The community has a CA signed SSL certificate and a custom domain setup via the Domains setup.
A community (“Community 2”) for customers at comm2.example.com. The community has a CA signed SSL certificate and a custom domain setup via the Domains setup.
A Customer Community profile with the SSO community as the default community. This profile I use to control access to the communities in Members.
I next configured the Salesforce as an Identity Provider using a self-signed certificate. This will allow the org to act as an IdP in a SAML authentication flow.
Next I created 2 Single-Sign-On configurations (under “Single-Sign-On Settings” in Setup). One for comm1.example.com and one for comm2.example.com with separate, unique, entity IDs and mapping each to the appropriate community as the only login configuration under Workspaces/Administration/Login & Registration. I used “Federation ID” for the SAML Identity Type. Ensure you use the SAML configuration from the SSO community.
Next configure the SSO community to only use “Username & Password” under Workspaces/Administration/Login & Registration. This ensures the customers actually are able to login using their Salesforce credentials.
Under “App Manager” in Setup create a Connected App for each community configuring SAML and using the appropriate entity ID remembering to also set these to use Federation ID.
Allow the community user profile to use the Connected Apps (both of them) and ensure user records have a federation ID set.
The result is that I can access all 3 communities on my custom domains. Accessing sso.example.com simply allows me to logon with username and password and do self-service incl. password reset etc. Accessing either comm1.example.com or comm2.example.com will redirect me to sso.example.com for authentication if not authenticated already. If already authenticated to sso.example.com it will simply bounce me via that and authenticate the user to the community transparently.
I had a need to test custom domains with Salesforce Communities and be able to log into those communities. When authenticating to a Salesforce Community an encrypted connection (meaning SSL) is required so I needed an easy and free way to generate certificates for my domains The solution was using openssl for the signing and Firefox for the testing as the latter comes with its own Trust Store. Lately many browsers has become very picky about what root certificates are trusted making this kind of testing harder.
Below are the steps I used:
Generate a private key for the root certificate authority: openssl genrsa -des3 -out rootCA.key 4096
Selg-sign and create a certificate with the private key: openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.crt
Convert the certificate to PEM format for import into the Firefox Trust Store: openssl x509 -in rootCA.crt -pubkey > rootCA_publickey.pem
Now in Salesforce Setup using “Certificate and Key Management” use “Create CA-Signed Certificate” and fill in the form. Then download the Certificate Signing Request (CSR) to your machine and then sign the CSR: openssl x509 -req -in my_csr_file.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out my_csr_file.crt -days 365 -sha256
Back in Salesforce on the key/pair created above use “Upload Signed Certificate” and pick the my_csr_file.crt signed above.
Now the certificate may be mapped to a custom domains (under “Domains”) having Salesforce terminate the SSL connection.
When doing development on Heroku using review apps, pipelines and all the other goodness it’s sometimes required to test against a clone of a production database. Doing that is pretty easy on Heroku when you know how even without moving the data down to your own laptop and then backup to Heroku. This is done by creating a backup, generating a public, secret, URL for the backup image and then restoring from that URL.
Below are the steps in the Heroku CLI to clone a database from an app called “my-production-app” to an app called “my-development-app”. Step no. 3 is to create a new Heroku Postgres addon attached to “my-development-app” that fits the same amount of data as the one from “my-production-app”.
$ heroku pg:backups:capture --app my-production-app
Starting backup of postgresql-aerodynamic-55964… done
Use Ctrl-C at any time to stop monitoring progress; the backup will continue running.
Use heroku pg:backups:info to check progress.
Stop a running backup with heroku pg:backups:cancel.
Backing up DATABASE to b003… done
$ heroku pg:backups:url --app my-production-app b003
$ heroku addons:create heroku-postgresql:hobby-basic --app my-development-app
Creating heroku-postgresql:hobby-basic on ⬢ my-development-app… $9/month
Database has been created and is available
! This database is empty. If upgrading, you can transfer
! data from another database with pg:copy
Created postgresql-octagonal-31270 as HEROKU_POSTGRESQL_YELLOW_URL
Use heroku addons:docs heroku-postgresql to view documentation
$ heroku pg:backups:restore --app my-development-app https://xfrtu.s3.amazonaws.com/112d4cf2-xxxx-475b-xxxx-ac809400fa78… HEROKU_POSTGRESQL_YELLOW
Once restored you may promote the database you restored into using the “heroku pg:promote” command and / or delete the backup you created.
$ heroku pg:backup:delete --app my-production-app b003 ▸ WARNING: Destructive Action ▸ This command will affect the app my-production-app ▸ To proceed, type my-production-app or re-run this command with --confirm ▸ my-production-app
Had a question come in from a customer that centered around understanding the difference between 2 legged and 3 legged OAuth so I thought I would write a little about it. I short 2 legged and 3 legged OAuth refers to the number of players involved in the OAuth dance but let’s explain each.
3 legged OAuth is used when you as a user wants to allow an application (i.e. Salesforce) to access a service (i.e. Azure) on your behalf without the application (Salesforce knowing your credentials for the service (Azure). This is accomplished by me (the user) being redirected by the application (Salesforce) to the service (Azure) where I log in directly, I obtain a code that the application (Salesforce) can use to obtain an access token for the service (Azure) out of band (i.e. the application contacts the service directly). Key is that I the user am involved because I need to authenticate to the service (Azure) and the application is afterwards able to impersonate me towards the service.
2 legged OAuth is used when an application needs to access a service using a service account (e.g. an App Registration as it’s called in Azure). The key here is that the application has all the information it needs to authenticate to the service. In 2 legged OAuth the application makes a single call to the service to basically exchange credentials (username/password, client_id/client_secret, Json Web Token (JWT)) for an access token. As an aside there is usually no way to get a refresh token issued in a 2 legged OAuth dance which is fair as the application could just perform the 2 legged OAuth dance again to get a new access token hence no need for a refresh token.
Looking back towards Salesforce and Named Credentials which is the way we recommend customers manage credentials for accessing services outside Salesforce. In Named Credentials you can use 3 legged OAuth if you selected “OAuth 2.0” for “Authentication Protocol” and 2 legged OAuth if you select “JWT” for “Authentication Protocol”.
During our regional (Nordic) kickoff last week (while I was skiing with my family) I was proud and happy to hear that I’d been awarded the Outstanding SE Achievement award. Picked up the award today including the accompanying two bottles of champagne. Very nice.