This is a technical article, targeting network and system engineers that have an intimate knowledge of Azure AD and SAML.
Before we get started with our how-to video, you can pre-fill the LLXP Single Sign On config area with these values which are standard for Azure:
Config Item | Value |
NameID format | urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress |
Email Attribute | |
First Name Attribute | |
Last Name Attribute | |
Unique User ID |
Obscure Tips
Azure AD needs for the metadata Issuer to match the ID; around the 1 minute mark in the video, you'll see that we copy the LLXP URL as we configure "Basic SAML Configuration". The recipe for these two values (seen in the video, careful of trailing slashes!) is:
Key | Value | Example |
Identifier | URL/saml/metadata/ | |
Reply URL (ACS) | URL/saml/acs/ |
On SP Cert Expiry
You'll notice that the AD panel notes with a warning, that the SP cert is expired. You'll also see in the video, that it still works just fine.
SP certs are destined for server-to-server exchanges, so their expiry isn't as sensitive as say, a website SSL cert would be. SSL certs expire to ensure that issuers can apply the latest security standards. If you examine the signature on our SP cert, you will see that it is using a very standard and recent composition.
What's most vital to consider, however, is that the SAML2 payload that is encrypted with this SP cert is still posted over SSL with a valid cert.
The Video
You might want to link out directly to YouTube to watch this in HD! It's very small otherwise!