w00t! Passed another Salesforce certification this evening and now there is only 2 more certifications left before both sides of the Salesforce Certified Technical Architect (CTA) triangle are done.
If you develop with the Salesforce API’s the following will save you a lot of time and make your life a lot easier. In our ongoing effort to make the Salesforce API’s easier to consume our Developer Relations have built a Postman Collection with 200+ requests. I know I’ve spent a lot of time to maintain my own collection for demos – that time is over!
The collection covers the following Salesforce APIs:
The collection and instructions are available on Github and there is even a webinar to help you get going.
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.
It just came to my attention that the component has been renamed to Time Warp and is available on the AppExchange (https://appexchange.salesforce.com/appxListingDetail?listingId=a0N4V00000GXVf4UAH). w00t! Being on the AppExchange makes it even easier to install and I highly recommend you take a look at this awesome component.
(Image from Github, https://github.com/deejay-hub/timeline-lwc)
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.
$ keytool -importkeystore -srckeystore ./00D090000046d3F.jks -srcstorepass Passw0rd -srcalias landing_site_pk -destalias landing_site_pk -destkeystore ./00D090000046d3F.p12 -deststoretype PKCS12 -deststorepass Passw0rd -destkeypass Passw0rd Importing keystore ./00D090000046d3F.jks to ./00D090000046d3F.p12... $ openssl pkcs12 -in ./00D090000046d3F.p12 -nodes -nocerts -out 00D090000046d3F.pem Enter Import Password: MAC verified OK $ cat 00D090000046d3F.pem Bag Attributes friendlyName: landing_site_pk localKeyID: 54 69 6D 65 20 31 36 30 36 33 39 30 30 35 36 38 30 38 Key Attributes: -----BEGIN PRIVATE KEY----- MIIEuwIBA....bTe+Hzyz -----END PRIVATE KEY-----
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>
{"networkId": "0DB3V000000blOT","parentId": "00e3V000000OkzG"}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:
sso.example.com. The community has a CA signed SSL certificate and a custom domain setup via the Domains setup.comm1.example.com. The community has a CA signed SSL certificate and a custom domain setup via the Domains setup.comm2.example.com. The community has a CA signed SSL certificate and a custom domain setup via the Domains setup.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.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.
YMMV!
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.
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.
(SE is short for Solution Engineer)
Yay!
Tonight I took and passed the exam to become Salesforce Certified Sharing and Visibility Designer. This is one of the two missing certifications on my track to become a Salesforce Certified Application Architect. Very happy I passed and must say that it is among the hardest Salesforce certifications I’ve taken so far.
Not necessarily because of the topic but more because the questions asked are very long and very hard to decipher at times. Many questions seems to test your ability to read and understand English more than your ability to grasp sharing and visibility topics. Also for many of the questions you need to select 2 or 3 answers instead of the single radio-button answer of many other certifications.
lekkimworld.com 