What better way to follow up from the last two posts by combining the concepts. In "This week at BlueBolt", I present my solution for utilizing Auth0 to authenticate a user and then pass them back to Shopify utilizing the Multipass feature.
<a href="https://www.youtube.com/watch?v=8bF5ft-oOWU"><img src="/images/leeloo-dallas-auth0.jpg" alt="Leeloo Dallas Auth0 Multipass"></a>
The primary steps involved in this process include:
<ol>
<li><a href="#enable-multipass-on-shopify-account">Enable Multipass on Shopify account</a></li>
<li><a href="#create-an-auth0-application">Create an Auth0 Application</a></li>
<li><a href="#add-auth0-rule-to-create-multipass-token-and-redirect-user">Add Auth0 rule to create Multipass token and redirect user</a></li>
<li><a href="#update-shopify-theme-with-auth0-links">Update Shopify Theme with Auth0 Links</a></li>
<li><a href="#add-url-values">Add URL Values</a></li>
<li><a href="#optional-capture-first--last-name-during-signup">Optional: Capture First &#x26; Last Name During Signup</a></li>
</ol>
This post was updated on 2020-01-31, adding a <code>return_to</code> URL to redirect the user to after being authenticated by Shopify.
<h2>Prerequisites</h2>
Similar to how TalentLMS requires an upgraded subscription in order to utilize SSO, Shopify requires a Shopify Plus storefront. As a <a href="https://www.shopify.com/partners">Shopify Partner</a>, you can create development stores to test out any functionality you need to implement on a Plus store.
An Auth0 account is also required. Their free tier includes everything necessary, but even if it didn't, a newly created instance includes all paid features for a few weeks to get you started.
<h2>Enable Multipass on Shopify account</h2>
Log into the Shopify store, go to the <code>Settings</code> page and click into the <code>Checkout</code> window. Customer accounts need to be either optional or required. This will allow you to enable Multipass for the store.
<img src="/images/multipass-step1-shopify-enable.png" alt="Shopify - Settings - CheckOut - Customer accounts">
This Multipass secret will be used by the encryption routine to create a cipher that Shopify will be able to decrypt and verify that a Multipass request is legitimate. If you ever suspect that your Multipass key has been compromised, then Disable and re-Enable Multipass. This will generate a new secret key which you will need to copy into Auth0.
<h2>Create an Auth0 Application</h2>
Within the Auth0 dashboard, go to <code>Applications</code>, click <code>Create Application</code>, given it a name (like "Shopify Store" - this is publicly visible!) and choose the <code>Regular Web Application</code>.
<img src="/images/multipass-step2-auth0-createapp.png" alt="Auth0 - Applications - Create Application">
Skip the Quick Start; go to Settings.
For the following sections, you need to substitute <code>{shopify-domain}</code> with the domain of your particular store (ex: <code>sample-store.myshopify.com</code>)
<ul>
<li>Allowed Callback URLs: <code>https://{shopify-domain}/account</code></li>
<li>Application Login URI: <code>https://{shopify-domain}/account/login</code></li>
<li>Allowed Logout URLs: <code>https://{shopify-domain}/account/logout</code></li>
</ul>
Expand the Advanced Settings section and add these two key/value pairs under Application Metadata:
<ul>
<li>Key: shopify_domain; Value: <code>{shopify-domain}</code></li>
<li>Key: shopify_multipass_secret; Value <code>{multipass-secret}</code></li>
</ul>
<img src="/images/multipass-step3-auth0-appmetadata.png" alt="Auth0 - Applications - Advanced Settings - Application Metadata">
<h2>Add Auth0 rule to create Multipass token and redirect user</h2>
Now that we have a landing point for the Shopify store to send users to, we need to be able to pass the authenticated user back to the Shopify store. This is where Multipass comes into play.
<img src="/images/multipass-step4-auth0-createrule.gif" alt="Auth0 - Rules - Create Rule">
Start by creating a new Rule in Auth0, use the <code>Empty rule</code> template, give it a descriptive name (like: "Shopify Multipass"), and paste in <a href="https://gist.github.com/drovani/8199b1e0ffa1976c00af6781fcb98fbf#file-auth0-rule-shopify-multipass-js">the following code</a>.
<pre><code class="language-js">function (user, context, callback) {
 if (context.clientMetadata &#x26;&#x26; context.clientMetadata.shopify_domain &#x26;&#x26; context.clientMetadata.shopify_multipass_secret)
 {
 const RULE_NAME = 'shopify-multipasstoken';
 const CLIENTNAME = context.clientName;
 console.log(`${RULE_NAME} started by ${CLIENTNAME}`);

 const now = (new Date()).toISOString();
 let shopifyToken = {
 email: user.email,
 created_at: now,
 identifier: user.user_id,
 remote_ip: context.request.ip
 };
 if (context.request &#x26;&#x26; context.request.query &#x26;&#x26; context.request.query.return_to){
 shopifyToken.return_to = context.request.query.return_to;
 }

 if (context.user_metadata)
 {
 shopifyToken.first_name = user.user_metadata.given_name;
 shopifyToken.last_name= user.user_metadata.family_name;
 }

 const hash = crypto.createHash("sha256").update(context.clientMetadata.shopify_multipass_secret).digest();
 const encryptionKey = hash.slice(0, 16);
 const signingKey = hash.slice(16, 32);

 const iv = crypto.randomBytes(16);
 const cipher = crypto.createCipheriv('aes-128-cbc', encryptionKey, iv);
 const cipherText = Buffer.concat([iv, cipher.update(JSON.stringify(shopifyToken), 'utf8'), cipher.final()]);

 const signed = crypto.createHmac("SHA256", signingKey).update(cipherText).digest();

 const token = Buffer.concat([cipherText, signed]).toString('base64');
 const urlToken = token.replace(/\+/g, '-').replace(/\//g, '_');

 context.redirect = {
 url: `https://${context.clientMetadata.shopify_domain}/account/login/multipass/${urlToken}`
 };
 }
 return callback(null, user, context);
}
</code></pre>
<ul>
<li>Line 2: since Auth0 runs all rules for all authentications, we want to restrict this to just when the Auth0 Application has declared the <code>shopify_domain</code> and <code>shopify_multipass_seceret</code> metadata.</li>
<li>Line 4-6: Some minor logging, just to verify that the rule is being run.</li>
<li>Line 8-14: Shopify requires at least the <code>email</code> and <code>created_at</code> data points. For added information, we are also passing an <code>identifier</code> (in case multiple Auth0 accounts have the same email address) and <code>remote_ip</code> to ensure that this Multipass request can only be used by the same computer that sent the initial login request.</li>
<li>Line 15-17: If there is a <code>return_to</code> value in the query string, then add this to the Shopify token.</li>
<li>Line 19-23: In my <a href="/posts/2019/using-saml-2-0-with-auth0-to-authenticate-users-in-talent-lms/">TalentLMS/Auth0 post</a>, I describe how to grab first/last name when signing up a user. If that is in place, this will also add those data points to the Shopify account.</li>
<li>Line 25-36: These lines that do the actual encryption were taken from <a href="https://github.com/beaucoo/multipassify/blob/master/multipassify.js">a repository</a> that I found on GitHub, so thanks go to <a href="https://github.com/corymsmith">Cory Smith</a> from Calgary, AB for this one.</li>
<li>Line 38-40: This sets the destination for the authenticated user.</li>
</ul>
Once this rule runs, the user will be redirected back to the Shopify store. This is important, because if there are any Auth0 rules after this one, they will be completely skipped.
<h2>Update Shopify Theme with Auth0 Links</h2>
For this example, we are just going to add a link to login into Auth0. If you want to completely replace the Shopify Login process with Auth0, then instead of presenting the user with a login page, you can redirect the user directly to Auth0. As a Proof-of-Concept, though, this will require the user to manually click the link.
Start by editing the current theme (or whatever theme you want to use to test this out).
<img src="/images/multipass-step5-shopify-edit-theme.png" alt="Shopify - Online Store - Themes - Edit Code">
Open the Login page, typically under Templates you will find the <code>customers/login.liquid</code> file. Find a good place to add the link; I put it next to the "Create account" link.
<pre><code class="language-html">&#x3C;a href="{{ settings.auth0_login_url }}">Log in with Auth0&#x3C;/a>
</code></pre>
<img src="/images/multipass-step6-shopify-loginauth0link.png" alt="Shopify - customers/login.liquid">
You may also want to put a link on the registration page, located in the <code>customers/register.liquid</code> template. If you are completely replacing Shopify logins with Auth0, then this will be another page where you will redirect the user straight to Auth0 instead of requiring them to click on a specific link.
Next up is to replace the logout link with the Auth0 logout. There is a logout link on the account page, found in <code>customers/account.liquid</code>. If your theme has a logout link anywhere else, that will also need to be replaced with the following:
<pre><code class="language-html">&#x3C;a href="{{ settings.auth0_logout_url }}">{{ 'layout.customer.log_out' | t }}&#x3C;/a>
</code></pre>
Finally, we need to <a href="https://help.shopify.com/en/themes/development/theme-editor/settings-schema">configure the theme settings</a> to allow a user to paste the login and logout urls. Open the <code>settings_schema.json</code> file and paste the following snippet to the end of the array. This will provide an admin user the ability to key in the URL value without having to modify the theme templates directly.
<img src="/images/multipass-step7-shopify-settingsschema.png" alt="Shopify - settings_schema.json">
This snippet creates a new settings section called "Auth0 Config" and add the two input that we need. Note that the <code>id</code> property matches the name of the properties we used above for the login and logout links.
<pre><code class="language-json">{
 "name": "Auth0 Config",
 "settings": [
 {
 "type": "text",
 "id": "auth0_login_url",
 "label": "Auth0 Login Url",
 "info": "The full Auth0 URL to redirect the customer to for login."
 },
 {
 "type": "text",
 "id": "auth0_logout_url",
 "label": "Auth0 Logout Url",
 "info": "The full Auth0 URL to redirect the customer to for logout."
 }
 ]
}
</code></pre>
<h3>Add URL Values</h3>
To put the values for the Auth0 URLs, you can either directly edit the <code>settings_data.json</code> file or you can use the Shopify admin UI. I prefer the UI, because then Shopify handles escaping any necessary characters.
Let's first build the login URL. Go back to Auth0 and copy the <code>Client ID</code> for your application (it's the one created in step 2).
<img src="/images/multipass-step8-auth0-clientid.png" alt="Auth0 - Applications - Client ID">
<ul>
<li>auth0-instance: the URL for your Auth0 instance.</li>
<li>clientid: the value from Auth0</li>
<li>shopify-domain: the domain you want the user sent back to. This must match the Allowed Callback URLs initially specified.</li>
<li>return-to-path: this can either be set as a hardcoded value (like "account") or it can be dynamically replaced with JavaScript on the page. This is helpful if you want to override the login on the Cart page.</li>
</ul>
<pre><code>https://{auth0-instance}.auth0.com/authorize?response_type=code&#x26;client_id={clientid}&#x26;return_to=https://{shopify-domain}/{return-to-path}&#x26;scope=SCOPE&#x26;state=STATE
</code></pre>
The logout URL looks very similar:
<ul>
<li>auth0-instance: the URL for your Auth0 instance.</li>
<li>clientid: the value from Auth0</li>
<li>shopify-domain: the domain you want the user sent back to. This must match the Allowed Logout URLs initially specified.</li>
</ul>
<pre><code>https://{auth0-instance}.auth0.com/v2/logout?response_type=code&#x26;client_id={clientid}&#x26;returnTo=https://{shopify-domain}/account/logout
</code></pre>
Back to the Themes page, now click the <code>Customize</code> button, switch to the <code>Theme settings</code>, expand the <code>Auth0 Config</code> section, and paste the URLs from above.
<img src="/images/multipass-step9-shopify-settings.gif" alt="Shopify - Theme - Customize - Theme settings - Auth0 Config">
<h2>Optional: Capture First &#x26; Last Name During Signup</h2>
The final step is to customize the Sign Up page to require the user to enter values for First and Last name. The simplest way (that I found) to do this is to customize the login page in Auth0. Under <code>Universal Login</code>, click on the <code>Login</code> tab, toggle the "Customer Login Page" and select the "Lock" Default Template. This uses the <a href="https://auth0.com/docs/libraries/lock/">Auth0Lock</a> and for our purposes, we will be utilizing the <code>additionalSignUpFields</code> array <a href="https://auth0.com/docs/libraries/lock/v11/configuration#additionalsignupfields-array-">configuration option</a>. Add the following JSON snippet to the code block:
<pre><code class="language-json">additionalSignUpFields:[{
 name: "given_name",
 placeholder: "Enter your First Name"
},
{
 name:"family_name",
 placeholder:"Enter your Last Name"
}],
</code></pre>
And it should look something like this:
<img src="/images/sso-step7-customize-login-page.png" alt="Auth0 - Customize Sign Up Fields">
Click <code>Save Changes</code> and that should be it! Go back to Shopify's login page and you can test it out. To make sure it really works, log yourself out of Shopify, and when logging back in, click the <code>Log in with Auth0</code> link you created earlier. You can go through the Sign Up workflow, which should require First name, Last name, Email, and Password.
<h2>In Production</h2>
Once you are ready to force all users to use Auth0 to login, the <code>customers/login.liquid</code> template can be completely replaced with a redirect to the <code>auth0_login_url</code>. All links to the login page can be replaced with direct links to the same setting. Also, all logout links need their url to be replaced with the <code>auth0_logout_url</code> setting.

Authenticate Shopify Customers with Auth0

Prior to this week, I did not know who <a href="https://www.talentlms.com/">TalentLMS</a> is, what <a href="https://wiki.oasis-open.org/security/FrontPage#SAML_V2.0_Standard">SAML</a> does, and how <a href="https://auth0.com/">Auth0</a> fits into the SSO alphabet soup. However, when a client wants something figured out, that's what I am here to do! After pouring over documentation for both TalentLMS and for Auth0, going down several dead-end paths, and nagging a few of my coworkers to "try it again?", I now successfully (and very delicately) have credentials collected from Auth0 logging a user into TalentLMS.
The primary steps involved in this process include:
<ol>
<li><a href="#enable-saml20-sso-integration-in-talentlms">Enable SAML2.0 SSO integration in TalentLMS</a></li>
<li><a href="#create-an-auth0-application">Create an Auth0 Application</a></li>
<li><a href="#map-setting-in-talentlms">Map Setting in TalentLMS</a></li>
<li><a href="#create-auth0-rule-to-define-saml-mapping">Create Auth0 Rule To Define SAML Mapping</a></li>
<li><a href="#capturing-first--last-name">Capturing First &#x26; Last Name</a></li>
<li><a href="#how-to-break-talentlms">How to Break TalentLMS</a>
<ol>
<li><a href="#talentlms-username-must-match-auth0-name">TalentLMS "Username" must match Auth0 "Name"</a></li>
<li><a href="#dont-switch-sso-login-screen-until-everything-works">Don't Switch "SSO login screen" Until Everything Works</a></li>
<li><a href="#talentlms-does-not-permanently-delete-users">TalentLMS Does Not Permanently Delete Users</a></li>
</ol>
</li>
<li><a href="#is-there-a-better-way">Is There a Better Way?</a></li>
</ol>
This post was updated on 2020-01-31, adding information about TalentLMS's <code>nameidentifier</code> requirements and how to lock down user accounts.
<h2>Prerequisites</h2>
TalentLMS requires a subscription level of Basic or above to implement Single Sign-On. I could not find any way around this, even temporarily. They don't have any sort of a "developer" plan or other trial period to be able to demonstrate a proof-of-concept. At $159.00 per month, one will need to invest at least that much to make this work. Thankfully, my client had no problem bumping up their subscription tier without even knowing if SSO would work.
An Auth0 account is also required. Their free tier includes everything necessary, but even if it didn't, a newly created instance includes all paid features for a few weeks to get you started.
<h2>Enable SAML2.0 SSO integration in TalentLMS</h2>
Over in TalentLMS, go to <code>Home / Account &#x26; Settings / Users</code> and change the <code>SSO integration type</code> to "SAML2.0".
<img src="/images/sso-step1-talent-settings.png" alt="TalentLMS - Settings - Users - SSO Integration type">
At the bottom of the page is the <code>Identity provider (IdP) configuration</code> section. There are values in here that need to go over to Auth0.
<pre><code>The Entity ID is:
{instance}.talentlms.com

The Assertion Consumer Service (ACS) URL is:
https://{instance}.talentlms.com/simplesaml/module.php/saml/sp/saml2-acs.php/{instance}.talentlms.com

The Single Logout Service URL is:
https://{instance}.talentlms.com/simplesaml/module.php/saml/sp/saml2-logout.php/{instance}.talentlms.com
</code></pre>
<h2>Create an Auth0 Application</h2>
Within the Auth0 dashboard, go to <code>Applications</code>, click <code>Create Application</code>, given it a name (like "TalentLMS") and choose the <code>Regular Web Application</code>.
<img src="/images/sso-step2-auth0-createapp.png" alt="Auth0 - Applications - Create Application">
For now, skip the Quick Start and Settings; go to Addons and flip the toggle for "SAML2 Web App".
<img src="/images/sso-step3-auth0-saml2webapp.png" alt="Auth0 - Applications - SAML2 Web App">
Put the url for the TalentLMS instance as the <code>Application Callback URL</code> and paste the Settings JSON below (replacing "{instance}" with your value).
<pre><code class="language-json">{
 "mappings": {
 "user_id": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
 "email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
 "name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
 "given_name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname",
 "family_name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname",
 },
 "passthroughClaimsWithNoMapping": true,
 "mapUnknownClaimsAsIs": true,
 "logout": {
 "callback": "https://{instance}.talentlms.com/simplesaml/module.php/saml/sp/saml2-logout.php/{instance}.talentlms.com",
 "slo_enabled": true
 }
}
</code></pre>
Since TalentLMS requires a unique identifier (TargetedID), a First name, a Last name, and an Email, we need to have Auth0 capture all four fields on sign-up and pass them through with the SAML identity claim. This requirement is what took up the bulk of my time trying to figure out. We'll come back to adding all the finishing pieces needed to make it work.
After you click the <code>Save</code> button at the bottom of the modal, switch over to the <code>Usage</code> tab, and click on "Download Auth0 certificate". Save this file and open it in your favorite text editor. It will look something like this:
<pre><code>-----BEGIN CERTIFICATE-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDMYfnvWtC8Id5bPKae5yXSxQTt
BAMTEGhjLXBvYy5hdXRoMC5jb20wHhcNMTkxMTA4MTgwNzM0WhcNMzMwNzE3MTgw
NzM0WjAbMRkwFwYDVQQDExBoYy1wb2MuYXV0aDAuY29tMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAvyV51yFcm+SJgWT8AKcw0uFTFRZnjkrmJZCMuKvC
+Zpul6AnnZWfI2TtIarvjHBFUtXRo96y7hoL4VWOPKGCsRqMFDkrbeUjRrx8iL91
KjIU8w3a8+9TDRpVbTLYtG9t8f1SjDcroBHLaF1XE8gH253L3tzK0Vfw3v7SHM9V
lso3/gsf/CfJIxQXVkCtUinRElRAIGbSSuOL9fP5Coy29uC4h+w+Tkan0IQsVoTu
bE5TH49mTN/ZF9Pcio1dktJOLVi+Ww4yl9l4Qbu4K4tEK4FXWyNqTDc+11SFd2uU
C3RMtsyO6qT+KeuwBtBjqgKHjB0jl1Yn/Du8ljPESb2mgwIDAQABo0IwQDAPBgNV
HRMBAf8EBTADAQH/MB0GA1UdDgQWBBRXd2raOpQViBgFHsR9seM1fN9CdTAOBgNV
4/srnyf6sh9c8Zk04xEOpK1ypvBz+Ks4uZObtjyQjtQ8mbDOsiLLvh7wIDAQABad
1l1v5K/yIqt1b17mtnIw5EXGpnwe2INxeUVvOz2eQAff1UdmyKh605LUKAFd9SZk
DnRiFU4QD0yenFkSlpnjU3Xy7UzGg2Nv5j/d8RsPGrg+pJDVGwFSriEg1TQQX4ZX
MhcxkOZFsw+EjKjx8j9x6gDZ3q+e5GvTPNO/jUX9gfO8Bz8SnhKyDiqHtvZhkBlG
yQjtQ8mbDOsiLLvh7wIDAQAB/5ml3plqk252APWd9hsW1IbLCrc4yttA6usDYJ1d
zohmAMID02C7cYoiR1e2dK+wjHsuBGptjGmOkL44ZjjY1FCljomvzYalCFeNeHo=
-----END CERTIFICATE-----
</code></pre>
<h2>Map Setting in TalentLMS</h2>
Flipping over to that other tab (you didn't close it, right? Because there's a lot more of this back-and-forth to do) - now we can fill out most of these values:
<img src="/images/sso-step4-talentlms-saml.png" alt="TalentLMS - SAML - Settings">
<ol>
<li>The <code>Identity provider</code> in TalentLMS matches the <code>Issuer</code> in Auth0.</li>
<li>Click the "or paste your SAML certificate" link and drop in the big block of random looking characters from the PEM file.</li>
<li><code>Remote sign-in URL</code> comes from Auth0's <code>Identity Provider Login URL</code>.</li>
<li><code>Remote Sign-out URL</code> is the <code>Identity Provider Login URL</code> with "/logout" appended.</li>
<li><code>TargetedID</code>, <code>First name</code>, <code>Last name</code>, and <code>Email</code> get the schema values from the <code>mappings</code> section of the Auth0 JSON.</li>
</ol>
Now that everything has been pasted into their respective fields, go ahead and click the <code>Save and check your configuration</code> button. You should be prompted to Log In or Sign Up. Proceed with signing up, which should then kick you back to the TalentLMS "Check your SSO configuration" page.
<img src="/images/sso-step5-login-signup.png" alt="TalentLMS Check your SSO configuration">
<h2>Create Auth0 Rule To Define SAML Mapping</h2>
There are two pieces still missing: sending the <code>given_name</code> and <code>family_name</code> fields from Auth0, and capturing those fields during the Sign Up process.
Auth0 stores any additional data that is captured into <code>user_metadata</code>, which can be viewed in <code>Users &#x26; Roles -> Users</code>, select a user, then scroll down to the <code>Metadata</code> section. The next step is in our process to add these SAML configuration mappings to pull data from the <code>user_metadata</code>. To do this, we are going to add a new Auth0 rule. Click on <code>Rules</code>, <code>+ Create Rule</code>, select <code>&#x3C;/> Empty rule</code>. Give it a name like "TalentLMS SAML Mappings" and <a href="https://gist.github.com/drovani/41b6f9c5acb186e8ca5ef4b4c7321c54#file-auth0-rule-talentlms-samlmapping-js">paste the following</a> into the Script section:
<pre><code class="language-js">function (user, context, callback) {

 if (context.clientID === '{{auth0-application-client-id}}') {

 const RULE_NAME = 'talentlms-samlmappings';
 const CLIENTNAME = context.clientName;
 console.log(`${RULE_NAME} started by ${CLIENTNAME}`);

 if (!user.user_metadata.given_name || _.isEmpty(user.user_metadata.given_name) ||
 !user.user_metadata.family_name || _.isEmpty(user.user_metadata.family_name))
 {
 console.log(`${RULE_NAME} Insuffient user_metadata for TalentLMS - given_name: ${user.user_metadata.given_name} family_name: ${user.user_metadata.family_name}`);
 callback(null, user, context);
 }

 var auth0Identity = _.find(user.identities, function(u) { return u.provider === 'auth0'; });
 var alphanumericUserId = auth0Identity.provider + auth0Identity.user_id;

 user.app_metadata = user.app_metadata || {};
 user.app_metadata.alphanumeric_auth0_user_id = alphanumericUserId;

 context.samlConfiguration.mappings = {
 "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier": "app_metadata.alphanumeric_auth0_user_id",
 "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress": "email",
 "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/given_name": "user_metadata.given_name",
 "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/family_name": "user_metadata.family_name"
 };

 }

 callback(null, user, context);
}
</code></pre>
<ul>
<li>Line 3: substitute {{auth0-application-client-id}} with the <code>Client ID</code> value for this Auth0 application. This ensures the rule only runs for the Auth0 application configured for TalentLMS login.</li>
<li>Line 5-7: simple logging to validate the rule runs when it is supposed to</li>
<li>Line 9-14: validate that the first and last names have been captured already, otherwise abort. A subsequent rule can be made to enable <a href="/posts/2019/auth0-progressive-profiling-proof-of-concept/">Progressive Profiling</a></li>
<li>Line 16-20: strip out the pipe in the Auth0 id, assign it to the cached <code>user</code> object</li>
<li>Line 22-27: map the fields from the rule's scope of variables to the SAML schema.</li>
</ul>
Click <code>Save Changes</code>. You can even click <code>Try This Rule</code>.
<ol>
<li>Replace the <code>User</code> part of the test input:</li>
</ol>
<pre><code class="language-json">{
 "name": "jdoe@foobar.com",
 "email": "jdoe@foobar.com",
 "user_id": "auth0|0123456789",
 "nickname": "jdoe",
 "picture": "http://foobar.com/pictures/jdoe.png",
 "identities": [
 {
 "provider": "auth0",
 "user_id": "0123456789",
 "connection": "Username-Password-Connection",
 "isSocial": false
 }
 ],
 "user_metadata": {
 "given_name": "John",
 "family_name": "Doe"
 }
}
</code></pre>
<ol>
<li>Replace the <code>clientID</code> portion of the <code>Context</code> script with the same value used in the rule.</li>
</ol>
After clicking the <code>Try</code> button, the "Output" should indicate that the rules context has a <code>samlConfiguration</code> object containing a <code>mappings</code> object that matches when you entered above.
<h2>Capturing First &#x26; Last Name</h2>
The final step is to customize the Sign Up page to require the user to enter values for First and Last name. The simplest way (that I found) to do this is to customize the login page in Auth0. Under <code>Universal Login</code>, click on the <code>Login</code> tab, toggle the "Customer Login Page" and select the "Lock" Default Template. This uses the <a href="https://auth0.com/docs/libraries/lock/">Auth0Lock</a> and for our purposes, we will be utilizing the <code>additionalSignUpFields</code> array <a href="https://auth0.com/docs/libraries/lock/v11/configuration#additionalsignupfields-array-">configuration option</a>. Add the following JSON snippet to the code block:
<pre><code class="language-json">additionalSignUpFields:[{
 name: "given_name",
 placeholder: "Enter your First Name"
},
{
 name:"family_name",
 placeholder:"Enter your Last Name"
}],
</code></pre>
And it should look something like this:
<img src="/images/sso-step7-customize-login-page.png" alt="Auth0 - Customize Sign Up Fields">
Click <code>Save Changes</code> and that should be it!
Flip back to the TalentLMS <code>Check your SSO configuration</code> page, click the <code>Log out</code> button (to clear your Auth0 session), and click the <code>Log in</code> button. Once you do so, you should now have four green checkmarks!
<img src="/images/sso-step6-successfully-logged-in.png" alt="TalentLMS - Successfully logged in.">
If you get an error here, it is probably because the profile you are using did not have a <code>given_name</code> and <code>family_name</code> in the user's meta data. Within Auth0, go to <code>Users &#x26; Roles -> Users</code>, edit the user you are logging in with, scroll down to the <code>user_metadata</code> window and add the following:
<pre><code class="language-json">{
 "given_name": "TestGivenName",
 "family_name": "TestFamilyName"
}
</code></pre>
Save changes, go back to TalentLMS, and attempt to log in again.
<h2>How to Break TalentLMS</h2>
The major problem I found with this solution is that it is extremely fragile. There are several ways to completely break logging in.
<h3>TalentLMS "Username" must match Auth0 "Name"</h3>
When setting us TalentLMS for SAML, the field that gets mapped to "TargetedID" becomes the user's "Username". By default, this is editable by the user in TalentLMS. If the user changes that value in TalentLMS, then the next time Auth0 sends over the authenticated user information, the values won't match. TalentLMS will then try to create another user, but will fail because the email address is already on an existing account.
Thankfully, the steps are straightforward in how to disable the ability for a user to change their username in TalentLMS:
<ol>
<li>From the administrator panel, click on "User types"</li>
<li>Click the edit icon next to the Learner-Type</li>
<li>Expand the General -> Profile tree</li>
<li>Disable "Update" and "Reset password" settings</li>
<li>Click the Save button</li>
<li>Repeat these steps for Trainer-Type and Admin-Type (you cannot remove the ability from the SuperAdmin user type)</li>
</ol>
<img src="/images/sso-step8-talentlms-disable-profile-update.png" alt="TalentLMS - Disable Profile Editing">
<h3>Don't Switch "SSO login screen" Until Everything Works</h3>
At the bottom of the Users settings page in TalentLMS is an innocent looking drop down list with the label of "SSO login screen" with two options: "Login page + IdP login link" and "IdP login page". Since I was just testing things out, I flipped the option to the second of the two, clicked "Save" and promptly locked myself (and everyone else) out of the TalentLMS instance. It required submitting a support ticket to have them revert the setting - quite an embarrassing moment, since I had to go back to the client and have them verify to customer support that this change needed to be made. TalentLMS should really have a modal pop up that says:
<blockquote>
Are you sure? Because if SSO login isn't perfectly working, you're going to screw things up. Also, if you haven't already made a SSO user a "SuperAdmin" you should do that, or you won't be able to get back into the administrative dashboard to fix any SSO settings.
Save Changes? or Revert?
</blockquote>
After you have everything working with SSO, and have an SSO user as a SuperAdmin, then you can change the login to be "IdP login page". This will force users directly to Auth0 to authenticate, removing the step of clicking the "Log in with SAML 2.0" link.
<h3>TalentLMS Does Not Permanently Delete Users</h3>
In my testing, I would frequently delete a user from both TalentLMS and Auth0 so that I could restart the entire sign up / log in workflow from the beginning. However, I quickly ran into an issue where TalentLMS would claim that an email address was already taken - even though I knew I had deleted the user.
It turns out that TalentLMS only soft-deletes users (even if an Admin clicks the Delete button). If you want to <a href="https://help.talentlms.com/hc/en-us/articles/360014658253-How-to-delete-users-and-courses-permanently">permanently delete users</a> you need to go through the convoluted process to permanently delete them. Thankfully, the Knowledge Base article was easy to find.
<h2>Is There a Better Way?</h2>
TalentLMS and Auth0 also support OpenID Connect as an SSO option, so that would also be an option. I don't have a good reason why I went with SAML over OpenID. Maybe someone else can share their experience and we'll see what the advantages for each might be.

Using SAML 2.0 with Auth0 to Authenticate Users in TalentLMS

Shopify has a feature that allows an external service to automatically log a user into the store from a third-party application. This is commonly used when integrating a Shopify store with a larger website product like Wordpress, DNN, or Drupal. Shopify calls this feature "<a href="https://help.shopify.com/en/api/reference/plus/multipass">Multipass</a>". Of course, this means for the last two days, all I can hear in my head is "Leeloo Dallas Multipass"; but even worse than having it on repeat (in my head) is that no one else on the project gets the reference.
<a href="https://www.youtube.com/watch?v=8bF5ft-oOWU"><img src="/images/leeloo-dallas-auth0.jpg" alt="Leeloo Dallas Auth0 Multipass"></a>
Now that that's out of the way - on to the project at hand. For a client that we are working with at BlueBolt, the desire is to use <a href="https://azure.microsoft.com/en-us/services/active-directory-b2c/">Azure AD B2C</a> as the backing authentication mechanism. The user experience is simple: the customer clicks the "Login" button, they are sent to an Azure AD B2C login form, then redirected back to the Shopify store. However, as we all know, nothing is as easy as it seems.
The implementation of the actual authentication is being done by a different consulting firm. For our part, we are just working on the front-end of the Shopify store (creative, templates, etc.) and I was brought on to support the external integrations.
After hours of working through how to get a valid Multipass URL to work, I finally was able to put together <a href="https://gist.github.com/drovani/df732f165d9735ad635707db1020d55d#file-shopify-multipass-demo-cs">the following gist</a>:
<pre><code class="language-csharp">string secret = "[shopify-multipass-secret]";
string store = "[shopify-store]";
var json = System.Text.Json.JsonSerializer.Serialize(new {
	email = "[customer-email]",
	created_at = DateTime.Now.ToString("O"),
	identifier = "[customer-uid]",
	//remote_ip = ""
});

var hash = System.Security.Cryptography.SHA256.Create().ComputeHash(Encoding.UTF8.GetBytes(secret));
var encryptionKey = new ArraySegment&#x3C;byte>(hash, 0, 16).ToArray();
var signatureKey = new ArraySegment&#x3C;byte>(hash, 16, 16).ToArray();

var initvector = new byte[16];
new System.Security.Cryptography.RNGCryptoServiceProvider().GetBytes(initvector);

byte[] cipherData = new Func&#x3C;byte[], byte[], byte[]>((iv, key) =>
{
	byte[] encrypted;
	using (var aes = System.Security.Cryptography.Aes.Create())
	{
		aes.Key = encryptionKey;
		aes.IV = iv;
		aes.Mode = System.Security.Cryptography.CipherMode.CBC;

		var encryptor = aes.CreateEncryptor(aes.Key, aes.IV);
		using (MemoryStream ms = new MemoryStream())
		using (System.Security.Cryptography.CryptoStream cs = new System.Security.Cryptography.CryptoStream(ms, encryptor, System.Security.Cryptography.CryptoStreamMode.Write))
		{
			using (StreamWriter sw = new StreamWriter(cs))
			{
				sw.Write(json);
			}
			encrypted = ms.ToArray();
		}
	}
	return encrypted;
})(initvector, encryptionKey);

byte[] cipher = initvector.Concat(cipherData).ToArray();
byte[] signature = new HMACSHA256(signatureKey).ComputeHash(cipher);
string token = Convert.ToBase64String(cipher.Concat(signature).ToArray()).Replace("+", "-").Replace("/", "_");

string url = $"https://{store}.myshopify.com/account/login/multipass/{token}";
</code></pre>
<h2>Shopify Provides No Help</h2>
<img src="/images/shopify-invalid-multipass-request.png" alt="Invalid Multipass Request error">
The only help that Shopify provides to identify the problem is "Invalid Multipass request" and a <code>Request ID</code> at the bottom. However, this is no way to get any details about what the problem is - not even an API call (that I could find) that lets me take the <code>Request ID</code> and look at logs on the request. Instead, I had to just keep trying (over and over and over) until I happened to stumble on the right answer — and then it just worked.
<h2>Never Hand-code JSON</h2>
I am not really sure what I thought it was the right idea to hand-code the JSON, but that's how I started. Looking back, I don't even know why I thought to switch it to an anonymous object that a JSON library would serialize. However, that was the final task that took a non-functional Multipass request to one that worked.
In fact, when I sent the gist off to the vendor to show them a working example, they called me back and said they couldn't get it working in their code. After doing a screen share, I saw the developer had also hand-coded the JSON. I suggested he change it to the same that I had and low-and-behold, it suddenly started working. My gist was in .NET Core 3.0, which meant they didn't have access to the <code>System.Text.Json</code> library. However, using <a href="https://www.newtonsoft.com/json">Newtonsoft's Json.NET</a>, we were able to quickly get a solution that worked.
<h2>Shopify App for Azure AD B2C</h2>
Now I'm wondering if there is any kind of a market for a Shopify App that acts as the necessary middle-ware between Shopify's Login page and Microsoft's Azure AD B2C.
If anyone out this is interested in developing it with me, hit me up. It could be an interesting project.

Shopify Multipass in .NET Core 3.0

All things considered, I am content with my performance at the 42nd running of the Bank of America Chicago Marathon. I had been battling a nasty couch all week, I wasn't able to train as hard as I initially hoped, and the weather was very windy. While I came no where close to hitting my Boston Qualifying time, I did manage to improve on my personal record. Finishing at 03:15:36, it beats my previous best by 01:39. By the time next year's Chicago Marathon comes around, I'll only need to lower my PR by six or seven minutes in order to get through to Boston.
<h2>The Night Before And Morning Of</h2>
I am constantly forgetting to create a night-before packing list, so hopefully I'll remember in the future that I have done so here and maybe I'll revise this list, or correct it as-needed and post it with the next race.
<ul>
<li>Packed Into Backpack
<ul>
<li>Pre-race Supplies: glasses case, contacts, Glide stick</li>
<li>Corral+Race Clothes: shirt (bib already attached), socks, visor, sunglasses (shaded and yellow pairs), old socks (for hand warming)</li>
<li>Race Gear: HR band &#x26; monitor, gel/nutrient bars, ziploc bag (for phone)</li>
<li>Post-race Clothes: compression socks, boxers</li>
<li>Battery &#x26; cable for phone</li>
<li>Race shoes</li>
</ul>
</li>
<li>Prepare for Morning
<ul>
<li>Razor, toothbrush, toothpaste, towel</li>
<li>Laid out to wear: Running shorts, warm pants, warm shirt, socks, jacket, walking shoes</li>
<li>Queue coffee pot</li>
</ul>
</li>
<li>Morning-Of Task List
<ul>
<li>Shave, shower, brush teeth, get dressed</li>
<li>Fill coffee thermos, pack into backpack</li>
<li>Toast bread, add almond butter &#x26; banana</li>
<li>Depart house, eating breakfast while walking</li>
</ul>
</li>
</ul>
This was the first time departing the new house for a race, so I had a little trepidation about getting downtown. The Brown Line doesn't start running until 5:00, meaning I wasn't going to arrive at the CARA VIP Experience until 5:45. This turned out to be just fine - I get nervous about these things.
So I left my house at 4:45, got to the Rockwell platform with plenty of time to spare, rode the train to Adams/Wabash, and walked the half-block to the Palmer House. The CARA compound was a friendly as ever - lots of familiar faces in various states of wakefulness. I was among those still waking up. Coffee was helping, but slowly.
I remembered to pack nearly everything I needed (I forgot an old pair of socks as hand warmers). I went about my routine of slowly getting into corral+race gear.
<h2>Pre-Race Routine</h2>
The only race gear that I put on at home are my running shorts, and I wear my throw-away shirt and post-race pants while getting to the race. At the compound, I'll change into the rest of my race gear, swing by the bathroom to apply Glide, and then drop off the backpack at gear check. From there, it is a short walk to the CARA VIP Port-a-potties (the closest bathrooms to the start line without having to worry about access to the race's blue boxes).
This year, I departed the hotel earlier than I needed to. Security lines are such a crap-shoot that I feel like a five minute difference in departure time means a 20+ minute wait in the security line. I was smart, this year, by going to one of the later gates that was further away from the Wave 1 gate. There was already a line near Gate 1, but there was absolutely no line at Gate 4 - which also happened to be right by the CARA Ports. Definitely a double-win.
The morning was quite chilly, roughly 39°F (3.8°C), and it never got above 48°F (9°C) throughout the morning. Wind was swirling throughout the day, with a sustained speed of 7mph at the start, increasing to 20mph by race's end - gusting up to 29mph. The long-sleeves cotton t-shirt that I wore over my running clothes was enough to keep the chill off, though I did miss having the gloves/socks to keep my hands warm. I don't think I actually shed the chill until mile 5 or so.
<img src="/images/2019chi-prerace-corral.jpg" alt="David and Jay in Corral B, ready for the start of the 2019 Chicago Marathon">
As I was standing in Corral B, waiting for the race to start, I decided that my goal for the race was going to be to keep a BQ pace for the first 18 miles (roughly 2/3 of the race) and then do the best I could to PR from there. Doing the math, that meant that if I could hold 7:00/mile pace, I would leave myself with 01:11:15 to finish the last 8.2 miles (an 8:40/mile pace) and still PR. I knew that my training this summer had not lent itself to putting me in a good place to BQ, and I had been battling a nasty cold and cough all week. Setting realistic goals was my best chance for mental success.
<h2>Three Hours of Hell</h2>
<img src="/images/2019chi-thatsme.png" alt="David Rovani circled in the wide shot of the start of the Chicago Marathon">
The first fifteen minutes of a marathon always feel great. The excitement of all the runners around me is intoxicating, after feeling cold for an hour it was good to start moving, nothing is sore yet. Then, around mile two is when I usually have to explicitly mentally check back into the race, evaluate my form, double-check my pace - generally just make sure I'm doing everything I'm supposed to. That's also about when it hits me that, yes indeed, I'll be doing exactly this for another three hours.
Around mile 4 is when I get to start looking for my wife - always on the runners' left of the road. She is just this ball of excitement that helps carry me for the next few miles. I'll see her again around mile 11, which helps to break up that first half of the marathon. Then it's the mental game of getting myself to the halfway point.
Late in Mile 4, just before the second water station, I tried to eat the first half of a LaraBar. During training, I had found that half of a bar every four miles is what worked out best for me. However, with the cold I had, I couldn't breath at all through my nose, and I nearly choked on the bar. I barely got one small bite down, and I didn't want to sacrifice a lot of time having to walk and chew before the water stop. I pocketed a majority of the bar and soldiered on, hoping things would clear up later.
<img src="/images/2019chi-pitstop.png" alt="Quick Pit Stop at Mile 5.25">
Shortly thereafter, my bladder started really nagging me. I've been in this situation before, and the lesson learned was to take the time hit early, use the port-a-potty, and get back on course. So I did just that. According to my Garmin, I lost approximately 30s - not too terrible.
Come mile 8, I tried again to eat some LaraBar but with the same result. It was still early enough that I could hopefully modify my strategy without too much hard. I tossed the remainder of the bar and decided to do a quick gulp of Gatorade at each stop instead of only taking a half-cup of water with each piece of bar.
Mile 11 had a quick pause to kiss my wife, then onward to the halfway point. At 01:31:20 for the first 13.1 miles, that beat my best Half Marathon time (and was my second-fastest first-half of a marathon). It felt great to hit that milestone, but I could also tell that I was struggling. With the swirling wind, time lost to the pit stop, changes in my nutrition plan, and a general sense of dread at doing this for another hour-and-a-half, I almost gave myself a walking break right there. This was the earliest in a Chicago Marathon I had my mental "maybe I can't do this" - it happens every race at some point, but not this early.
<img src="/images/2019chi-mthalstead.png" alt="Mount Halstead - it doesn&#x27;t look big, but it sucks after 17 miles">
I reminded myself of my first goal - get to 18 miles at BQ pace. That meant I just had to keep it up for 5 more miles; just 35 more minutes. Then it was just 28 more minutes, then just 21 more minutes, then just 14 more minutes - ok, I can do this for two more miles. The Halstead overpass between mile 17 and 18 is always a struggle. It's a big hill (by Chicago standards) that is very exposed to wind and car noise, and previously has been the first point where I usually start regretting my life decisions. This year was no different. But I had to run to 18 - just 3 more minutes.
I did it. I got to mile 18, pulled off to the side, and had a coughing fit so hard that I nearly threw up. Shortly thereafter, the 03:05:00 pace group passed me. I slowly ran to the Gatorade energy gel table, squeezed down a packet of vanilla, grabbed some water to wash it down, and set off again. The new plan was to run for two miles then walk a little - four intervals and then it would be done.
Surprising even myself, that's exactly what I did for the rest of the race. The two miles of running was slow - averaging between 7:45 and 8:00/mile. I stopped looking at my watch, stopped worrying about pace. It was just about running to the next even mile marker, walking for a block, then running again. By the time the last stretch hit, I wanted to walk several times, but I just knew that if I started walking, I wasn't going to start running again. I just had to finish this and hope that I had put in enough time to still set a PR. I know I managed to smile and wave while crossing the finish line, and I remembered to stop my Garmin, but I didn't know whether I had PR'd or not. I had finished and that's what I cared most about.
<h2>Race Results - 03:15:36</h2>
<ul>
<li>Overall Place: 4117 of 45,755 (top 9%)</li>
<li>Gender Place: 3559 of 24,515 (top 15%)</li>
<li>Age Group Place: 754 of 4,110 (top 20%)</li>
</ul>
I had put so much focus at the beginning of the year on qualifying for Boston that it took a little bit for it to sink in that I had indeed set a PR. I definitely needed to be proud of that. I had also hit my goal of staying in front of the 03:05:00 pace group for 18 miles. I have always been terrible at recognizing the achievement of completing a marathon, much less doing it faster than I've done before. I get caught up in the lofty goal that I set and then get down on myself for not hitting it.
<img src="/images/2019chi-postrace.jpg" alt="Glad that I am finished">
Wrapping it all up, I am grateful for having set a new personal record. I am grateful for the love and support of my entire family for encouraging me all through training. I am especially grateful to my wife for putting up with all the highs, the lows, the early mornings, the bitching and complaining, the smelly clothes, and that she is still so excited to come out on a cold Autumn morning to see me for a grand total of probably two whole minutes. It always has meant a lot to me and continues to mean a lot.
<h2>Year-to-Year Comparisons</h2>
|Splits|2019 |2018 |2017 |2016 |2015 |2014 |
|------|--------|--------|--------|--------|--------|--------|
|05K |00:21:53|00:23:32|00:20:45|00:22:08|00:26:16|00:27:54|
|10K |00:43:40|00:46:42|00:42:06|00:44:15|00:51:34|00:54:53|
|15K |01:04:59|01:09:58|01:03:50|01:06:31|01:16:18|01:21:12|
|20K |01:26:31|01:32:52|01:25:53|01:28:28|01:42:16|01:47:59|
|Half |01:31:20|01:37:57|01:30:42|01:33:11|01:47:42|01:53:41|
|25K |01:48:40|01:56:21|01:48:08|01:50:37|02:07:07|02:13:52|
|30K |02:11:30|02:19:12|02:13:48|02:14:54|02:32:59|02:41:09|
|35K |02:36:02|02:42:39|02:40:24|02:41:40|03:05:53|03:07:24|
|40K |03:04:00|03:06:54|03:10:43|03:10:02|03:39:00|03:33:01|
|Finish|03:15:36|03:17:15|03:21:56|03:21:43|03:51:48|03:43:29|

2019 Chicago Marathon Race Review

<img src="/images/bluebolt-logo.png" alt="BlueBolt Solutions">
After nearly 7 years of full-time employment with IFCJ (and five years prior to that of part-time consulting work), I have chosen to move to other opportunities and challenges. This presented itself in the form of an offer from <a href="https://blueboltsolutions.com">BlueBolt Solutions</a> to join their team as a Senior Solutions Architect. My primary duties will consist of being a technical lead across several projects of varying size, architecting and scaffolding solutions, work with the project managers to ensure timely delivery of the completed project, and mentor junior/mid-level developers as they work on the project.
<h2>Day One - Initialization</h2>
As I expected, the first day was all about setting up my environment - getting applications installed, accounts initialized, paperwork completed. It has been quite a long time since I have built a work setup from scratch, so I fully expect to have forgotten tools that I used regularly. A (non-exhaustive) list of what I have already put in place:
<ul>
<li>Windows Subsystem for Linux (WSL) and Ubuntu</li>
<li>Visual Studio Code, including changing the default terminal to Bash and getting the environment set-up to run Bundler and Jekyll (for writing these posts).</li>
<li>Visual Studio 2019 Professional</li>
<li>Edge (Insiders, Chromium)</li>
<li>LastPass + Browser extensions</li>
<li>LinqPad</li>
<li>Microsoft Office Products
<ul>
<li>Teams</li>
<li>Outlook</li>
<li>OneNote</li>
<li>Word</li>
<li>Excel</li>
</ul>
</li>
<li>Node.js (for future React projects)</li>
<li>Spotify</li>
</ul>
<h2>Day Two - 8:00 Is Early?</h2>
I arrived at the building today at 8:00, only to find that it was locked! Thankfully, a delivery driver and an employee of another office in the building were both walking in just before me, and so I was able to walk in behind them. I'll have to find out when the building opens up, and how I can get access before then. Additionally, when I came up to the office, the lights were on and the door was unlocked, but there was no one inside. It's definitely a big change from IFCJ, where people started rolling in at 7:00, and the office was in full business mode by 8:00. I also need to get a key to the office and find out the feasibility of me starting work at 7:00. Will there be awkward moments when I'm leaving at 4:00? I'm sure it'll all work itself out.
Later in the day, I joked about being all alone in the office. I was given a set of keys, today - which is great. I can now come whenever I need to. I think I'm going to end up really appreciating the quiet in the morning - a chance to really get some dedicated work done.
<h2>Day Three, Four, Five - Getting Rolling</h2>
It turns out that there are about two other people who roll in before 8:30 - both of which seem to really like keeping a quiet, productive first hour or two. Which works out perfectly for me.
This first project, which fairly straight-forward, has its own set of challenges just getting up to speed. BlueBolt doesn't really have a formal structure for how projects, work items, branch policies, etc., are configured in Accelo or in Azure DevOps; however, this grants me incredible freedom to template the workflow how I would like it. Especially since the developer that will be doing the work is fresh to the company, there are no preexisting biases that I have to accomodate.
I'm going to keep detailed notes on what I created that worked out well and what needs tweaking for the next project. My long-term hope is to be able to get all of the Architects to converge on a very similar style of rules and structure in Azure DevOps, making it easier for developers to transition between teams.

First Week at BlueBolt Solutions

<img src="/images/2019-06-15-n1400.jpg" alt="N1400 for June 11th and 13th">
The first three weeks of the CARA summer marathon training are now in the books, and I am still trying to figure out how to best plan my running schedule. Because of schedule limitations (having three kids and a full-time job will do that), I can only really run on Tuesday and Thursday mornings by myself and Saturday mornings with the running group. In order to maximize the effects of these runs, I have started mentally adopting a "no easy runs" motto.
<h2>Intervals and Speedwork Twice a Week</h2>
Smart training plans include one or two days of speed work in a week, combined with three or four days of easy runs, in addition to a long run on the weekend. Getting from home to work can be a direct 7.5 mile run, an indirect route (east to the Lakefront Path, then south) of 10.5 miles, or really any distance longer than that. Since most speed workouts are shorter than this, I have to adapt my plans to accommodate the time I have. For example, a workout last week was:
<pre><code>Warmup (10 minutes or 2 miles)
2-3 sets (2x 200m + 1x 400m) @ 10k-5k pace
Equal jog recovery
Cooldown (10 minutes or 2 miles)
</code></pre>
This only adds up to 5-6 miles, which means I need to add a few more miles. Instead of 200m and 400m repeats, I just did 800m repeats.
<pre><code>Warmup
3 x 1 mile @ Tempo
1 minute rest
Cooldown
</code></pre>
This is workout is probably also only 5-6 miles, so my warm up was much longer and my cooldown was longer.
<h2>Weekly "No Easy Runs" Plan</h2>
To build these workouts, I am using the CARA <a href="https://drive.google.com/file/d/1Dhab_gIIOK0cGKpUCDZ4H9rsuP2qlZxv/view">Summer Marathon Training Program Guide</a> and taking the Monday and Wednesday speed workouts from the Advanced Training Plan. I am doing the same warmup routines, and then I am tacking on a few more miles to get.. um... really warmed up. The cooldown portion of the run I also try to maintain a slightly harder pace than I normally would.
For this upcoming week, my workouts are scheduled to be:
<pre><code>Tuesday: 4 miles @ Tempo pace (6:25/mile)
Thursday: 6-8 Yasso 800m (3:00/800m)
Saturday: 13 miles
</code></pre>
I'll report back here with an update on how it went.

Project BQ: No Easy Runs

<img src="/images/2019-06-04-n1400.jpg" alt="N1400 for June 4th">
June is here, which means the official beginning of the training season for the 2019 Chicago Marathon - only 130 days away. As I look ahead to what life is like now and will be by the time October comes around, I feel that this is my last, best hope (for a while, at least) to run a qualifying time for the Boston Marathon. Once this season is over, I will be undergoing back surgery, which the doctor estimates will take a year before I can be back to endurance running. This means I will be missing out on the 2020 season and potentially not getting back into BQ shape until the 2021 season - which puts me over 40 for the next time I can run Chicago.
Previous years, I have kept it quiet about my goal of running a Boston-qualifying time. Fellow runners would occasionally ask, and my first year thinking about it (2016) I kept coy with plenty of "we'll see what happens". I ran a 03:21:43 - only sixteen minutes away from going to Boston. During the 2017 training season, I was a little more open - "it would be nice, but there's a lot that would need to go right". 03:21:56 - I was no closer to my goal, and only getting older. Last year, I was very open - "I'm going for it this year - BQ or Bust!" I improved to 03:17:15, which is still over seven minutes short of qualifying and was almost 13 minutes short of getting to actually run.
To makes matters even worse, the organizing committee for the Boston Marathon has decide to lower the <a href="https://www.baa.org/races/boston-marathon/enter/qualify">qualifying times</a>. I now need to run faster than a 03:05:00 marathon just to qualify. Realistically, I am aiming for an even three-hours, as that will give me plenty of clearance to make the "cut-off" time. It is a lot to ask for, especially with a two-year-old and a newborn at home, a bad back in need of surgery, and an extra fifteen pounds of bodyweight that needs to be shed.
In an attempt to keep myself more accountable, I'm being very public about my goals this year. I am going to set milestones that I need to hit throughout the training season, rewards for when I get them, and documenting my journey. I'll be writing about my photo project, N1400; I will be tracking my workouts under my new motto of "No Easy Runs"; and I will be open and honest about how to manage relationships with friends, family, and coworkers throughout the season.
The next one hundred and thirty days are dedicated to my own <a href="https://twitter.com/hashtag/ProjectBQ">#ProjectBQ</a>.

Rovani's Sandbox

Blog Posts - Page 4