Table of Contents

Why Cache Access Token with MSAL?

Building upon the previous post that performs delegated access authentication with MSAL, suppose your program uses this function to get the access token.

def get_access_token():
    app = msal.PublicClientApplication(CLIENT_ID, authority=AUTHORITY)
    result = app.acquire_token_interactive(scopes=SCOPES)
    access_token = result['access_token']

    return access_token

In this case, it will always launch the browser to complete the authentication flow and retrieve the access token every time the program runs.

While it works, it introduces a slight latency to your program. Fortunately, MSAL provides the capability to cache the access token.

Solution A: Use custom persistence cache

In this solution, we can introduce our custom persistence cache.

First, we can use these functions to load the access token from the cache file and save it to the cache file.

import os
import msal

...
CACHE_FILE = 'msal_token_cache.json'

def load_cache():
    cache = msal.SerializableTokenCache()

    if os.path.exists(CACHE_FILE):
        with open(CACHE_FILE, 'rb') as f:
            cache.deserialize(f.read())

    return cache

def save_cache(cache):
    if cache.has_state_changed:
        with open(CACHE_FILE, 'wb') as f:
            f.write(cache.serialize().encode())

We can first attempt to get a valid access token from the cache. It will only get the token interactively via the browser if the access token doesn’t exist or has expired.

def get_access_token():
    cache = load_cache()
    app = msal.PublicClientApplication(
        CLIENT_ID,
        authority=AUTHORITY,
        token_cache=cache,
    )
    result = None
    accounts = app.get_accounts()

    if accounts:
        result = app.acquire_token_silent(SCOPES, account=accounts[0])

    if not result:
        result = app.acquire_token_interactive(scopes=SCOPES)

    save_cache(cache)
    access_token = result['access_token']

    return access_token

While this solution works, the implementation code is very lengthy. Furthermore, the access token is stored in the cache file as clear text.

Solution B: Use the OS platform’s encrypted vault (PREFERRED)

A Python package called msal-extensions allows the access token to be stored securely in the OS platform’s encrypted vault. For example, If the program runs on MacOS, KeyChain will be used. Windows uses DPAPI, and Linux uses LibSecret.

To begin, install that Python package.

# requirements.txt

msal
msal-extensions

The configuration is much simpler than Solution A.

import msal
from msal_extensions import build_encrypted_persistence, PersistedTokenCache

...
CACHE_FILE = 'msal_token_cache.json'

def get_access_token():
    app = msal.PublicClientApplication(
        CLIENT_ID,
        authority=AUTHORITY,
        token_cache=PersistedTokenCache(build_encrypted_persistence(CACHE_FILE)),
    )

    result = None
    accounts = app.get_accounts()

    if accounts:
        result = app.acquire_token_silent(SCOPES, account=accounts[0])

    if not result:
        result = app.acquire_token_interactive(scopes=SCOPES)

    access_token = result['access_token']

    return access_token

When running the program on MacOS, the access token is stored in the KeyChain.

Note: An empty cache file named msal_token_cache.json has also been created. Unfortunately, there is no option in msal-extensions==1.2.0 to disable the creation of this file at the moment.

The post MSAL: Caching Access Token appeared first on My Shitty Code.

Table of Contents

Why Launch a Specific Browser with MSAL?

Building upon the previous post that performs delegated access authentication with MSAL, your institution may sometimes allow you to access Microsoft 365 products only on the approved browsers.

By default, MSAL launches the default browser on your machine to obtain the access token interactively.

If your institution only allows Chrome and your default browser is Firefox, you will get the following message:

Overriding with BROWSER environment variable

MSAL relies on Python’s built-in module called webbrowser to launch the browser. This allows us to change the browser by setting the BROWSER environment variable to the predefined values (‘firefox’, ‘chrome’, etc.)

For example, to launch Firefox instead of the default browser, we can do this:

import os
import msal

# ... 
os.environ['BROWSER'] = 'firefox'
app = msal.PublicClientApplication(CLIENT_ID, authority=AUTHORITY)
result = app.acquire_token_interactive(scopes=SCOPES)

What if the BROWSER environment variable’s predefined value doesn’t work?

I discovered that Python’s webbrowser failed to launch the correct browser, especially when dealing with Chromnium-based browsers.

For example, suppose my default browser is Brave, and I set the BROWSER environment variable to Chrome. In that case, it will still launch the Brave browser.

# default browser = Brave

os.environ['BROWSER'] = 'chrome'  # doesn't work
app = msal.PublicClientApplication(CLIENT_ID, authority=AUTHORITY)
result = app.acquire_token_interactive(scopes=SCOPES)

Fortunately, it is possible to specify a full path ending with ‘%s’ instead:

# default browser = Brave

os.environ['BROWSER'] = 'open -a /Applications/Google\\ Chrome.app %s'  # works
app = msal.PublicClientApplication(CLIENT_ID, authority=AUTHORITY)
result = app.acquire_token_interactive(scopes=SCOPES)

If you are stuck on the “Approve sign in request” or “Set up your device to get access” screen indefinitely, consider clearing the browser cache and then try again.

The post MSAL: Launching Specific Browser with Delegated Access Authentication appeared first on My Shitty Code.

Table of Contents

The Microsoft Authentication Library (MSAL) supports various programming languages and frameworks to simplify the authentication flow against the Microsoft identity platform, which is a prerequisite to invoke APIs such as Microsoft Graph.

In this example, we will write a Python script that performs delegated authentication flow using the user’s credentials. Once authenticated, the script will pull the user’s OneNote data via Microsoft Graph.

Note: While we can also authenticate via app-only access, this is generally scrutinized in larger institutions due to the blast radius. This is because the app can modify other users’ content stored in Microsoft 365 products (emails, calendars, etc).

App Registration and Configuration

Even if you plan to run your program on your local machine, you must register it in the Azure Portal to generate a unique client ID to authenticate.

• Go to https://portal.azure.com/ and sign in.
• Go to App Registrations and register your app.
• Go to the registered app -> Manage (step 1) -> Authentication (step 2). Ensure the following configurations exist:
  • A Mobile and desktop applications platform with the redirect URI set as http://localhost (step 3).
  • The Access tokens (used for implicit flows) option is checked (step 4).

• Go to the registered app -> Manage (step 1) -> API permissions (step 2).
• Add the permissions you need (step 3). OneNote’s permissions are added in this example because the script will query OneNote via Microsoft Graph.
• Before we can call the Microsoft Graph API, these permissions must have green check marks (step 5), accomplished by clicking the Grant admin consent button (step 4). If this button is grayed out, request your institution’s Azure administrators to perform this step on your behalf.

Custom Python Program

Now that the app is registered and configured in the Azure Portal, we can work on the custom script.

Install the msal library.

# requirements.txt

requests
msal

Define the needed variables. The client ID and tenant ID can be retrieved from your registered app in the Azure Portal.

import msal
import requests

CLIENT_ID = '[YOUR_CLIENT_ID]'
TENANT_ID = '[TENANT_ID]'
AUTHORITY = f'https://login.microsoftonline.com/{TENANT_ID}'
SCOPES = ['Notes.Read', 'User.Read']

A function to perform the authentication and to retrieve the access token. MSAL will seamlessly create a web server running on localhost to accept the incoming token data (hence, the need to configure the redirect URI in the Azure Portal).

def get_access_token():
    app = msal.PublicClientApplication(CLIENT_ID, authority=AUTHORITY)
    result = app.acquire_token_interactive(scopes=SCOPES)
    access_token = result['access_token']

    return access_token

A simple function to query OneNote pages using Microsoft Graph.

def get_onenote_pages(access_token):
    url = 'https://graph.microsoft.com/v1.0/me/onenote/pages'

    headers = {
        'Authorization': f'Bearer {access_token}',
        'Accept': 'application/json'
    }

    response = requests.get(url, headers=headers)
    response.raise_for_status()

    return response.json()

Finally, run the app to test if the app registration and configuration are set up correctly in the Azure Portal.

def run():
    access_token = get_access_token()
    print(access_token)

    onenote_pages = get_onenote_pages(access_token)
    print(onenote_pages)


if __name__ == '__main__':
    run() 

The post MSAL: Delegated Access Authentication appeared first on My Shitty Code.

Typically, when using ZipDeploy to push a WAR file (ex: my-app.war) to an Azure instance, we need to:-

• Rename my-app.war to ROOT.war.
• Place ROOT.war under webapps/.
• Zip up webapps/.
• Use ZipDeploy to push the zip file to an Azure instance.

This zip file will automatically be unzipped under site/wwwroot:-

D:\home\site\wwwroot
└── webapps
    └── ROOT.war

Tomcat detects ROOT.war and will try to unpack the WAR file under ROOT/:-

D:\home\site\wwwroot
└── webapps
    ├── ROOT
    │   ├── META-INF
    │   │   └── ...
    │   └── WEB-INF
    │       └── ...
    └── ROOT.war

The problem is sometimes Tomcat is unable to fully unpack ROOT.war because some files may be locked by some running processes. As a result, the web page fails to load and shows 404 error.

SOLUTION

A better and more stable solution is to use WarDeploy to push WAR file to an Azure instance because:-

• It simplifies the deployment process because we don’t need to create a zip file with webapps/ containing a WAR file named ROOT.war.
• Instead of relying on Tomcat to unpack the WAR file, WarDeploy will do the unpacking step elsewhere before copying to site/wwwroot/webapps/.

To use WarDeploy, you can use curl command or PowerShell script to do so.

Here’s an example of the PowerShell script:-

Param(
    [string]$filePath,
    [string]$apiUrl,
    [string]$username,
    [string]$password
)

$base64AuthInfo = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f $username, $password)))

Invoke-RestMethod -Uri $apiUrl -Headers @{ Authorization = ("Basic {0}" -f $base64AuthInfo) } -Method POST -InFile $filePath -ContentType "multipart/form-data"

If the PowerShell script above is called deploy.ps1, to push my-app.war to my-app Azure instance:-

deploy.ps1 -filePath D:\my-app.war -apiUrl https://my-app.scm.azurewebsites.net/api/wardeploy -username [USER] -password [PASSWORD]

Depending on the size of the WAR file, you may get “The operation has timed out” error after 100 seconds:-

Invoke-RestMethod : The operation has timed out
At D:\agent\_work\2ea6e947a\my-app\deploy.ps1:18 char:1
+ Invoke-RestMethod -Uri $apiUrl -Headers @{Authorization=("Basic {0}"  ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-RestMethod], WebException
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeRestMethodCommand

This will most likely to occur if the WAR file is too big (80MB+).

To fix this, increase the time out duration by adding -TimeoutSec option to Invoke-RestMethod statement:-

Invoke-RestMethod [OTHER_OPTIONS...] -TimeoutSec 300

The post Azure: Deploying WAR File to Tomcat appeared first on My Shitty Code.