Securing domain name with Microsoft SSO
Maglr offers the option to secure a domain name. All publications shared under this domain are then protected and not visible to search engines. This security can be set up using a manual password, a secret link, or Single Sign-On (SSO, available with an Enterprise license).
Example: Internal Publications for Employees
Consider publications intended for internal use only. If your organization uses “Microsoft 365 / Azure AD,” the existing Microsoft authentication can be ideal for securing a domain like internal.companyname.com. While we use Microsoft as an example due to its widespread use in organizations, similar integrations can be set up with Google, Okta, etc.
How Does SSO Work for a Domain Name?
Accessing the Secure Domain:
When an employee navigates to a secured domain (e.g., internal.companyname.com), they are redirected to Microsoft’s login page.
Authentication with Microsoft:
If the employee is not already logged into Microsoft, they will need to log in.
Consent to Connect with Maglr:
The user will be prompted to consent to link their account with the Maglr app. This allows Maglr to read their email credentials. (Organizations can preconfigure this consent across the organization via Azure settings if they don’t want to leave this decision to individual users.)
Verification and Filtering:
After logging in and granting consent, the user is redirected back to Maglr. Based on the configured filter (e.g., email domain or group ID), Maglr determines whether the user is allowed access to the domain.
Access Granted:
If the user meets the filter criteria, they are redirected to the domain, where they can access its content.
Subsequent Access:
If the user returns to the domain later (and is still logged into Microsoft), they are directly redirected to the publication without seeing the authentication layer again—unless they have logged out.
Maglr App in Azure / Entra
The Maglr SSO domain protection operates via an intermediary Enterprise App, which can be found in the Microsoft Entra dashboard. By default, the app requests user.read permissions.
Name: Maglr
Application ID: 6a93cafe-ced9-4730-9c36-2ae21c39ea07
Object ID: db5e6f6d-6318-48b5-b174-8d6b6bf11fbe
Delegated Permissions
To simplify the consent process for employees, organizations can pre-approve permissions organization-wide. In Microsoft Entra -> Applications -> Enterprise Applications -> Maglr -> Permissions, these permissions can be managed.
the user.read profile permission
The following result is an example of the user.read information we get from Microsoft. Minimal company information including the GroupID's a user is a member of. With these variabels we can grant acces on e-mail or GroupID level.
Domain Filtering by Maglr
Maglr determines the filtering for the secured domain. Based on data received from the user.read profile, users can be granted or denied access. The filtering settings can be configured after consultation. The most common filter is by @domain, where users with an email address matching the organization’s domain are granted access.
Can I activate SSO on multiple domains set up within Maglr?
Yes, once the Maglr app is connected, we can create an SSO filter for multiple domains. The “consent” step does not need to be repeated; it is a one-time setup for the entire Maglr application.
Can I grant access to people outside my organization to publications behind my secured domain?
No, once secured, only Microsoft users who meet the configured filter criteria will have access to the publications.
Can I secure the dashboard itself with SSO for editors/designers in our organization?
Yes, this is possible. The authorization technically uses the same “Maglr App,” but the setup is managed within the dashboard itself. Read more.
Example: Internal Publications for Employees
Consider publications intended for internal use only. If your organization uses “Microsoft 365 / Azure AD,” the existing Microsoft authentication can be ideal for securing a domain like internal.companyname.com. While we use Microsoft as an example due to its widespread use in organizations, similar integrations can be set up with Google, Okta, etc.
How Does SSO Work for a Domain Name?
Accessing the Secure Domain:
When an employee navigates to a secured domain (e.g., internal.companyname.com), they are redirected to Microsoft’s login page.
Authentication with Microsoft:
If the employee is not already logged into Microsoft, they will need to log in.
Consent to Connect with Maglr:
The user will be prompted to consent to link their account with the Maglr app. This allows Maglr to read their email credentials. (Organizations can preconfigure this consent across the organization via Azure settings if they don’t want to leave this decision to individual users.)
Verification and Filtering:
After logging in and granting consent, the user is redirected back to Maglr. Based on the configured filter (e.g., email domain or group ID), Maglr determines whether the user is allowed access to the domain.
Access Granted:
If the user meets the filter criteria, they are redirected to the domain, where they can access its content.
Subsequent Access:
If the user returns to the domain later (and is still logged into Microsoft), they are directly redirected to the publication without seeing the authentication layer again—unless they have logged out.
Maglr App in Azure / Entra
The Maglr SSO domain protection operates via an intermediary Enterprise App, which can be found in the Microsoft Entra dashboard. By default, the app requests user.read permissions.
Name: Maglr
Application ID: 6a93cafe-ced9-4730-9c36-2ae21c39ea07
Object ID: db5e6f6d-6318-48b5-b174-8d6b6bf11fbe
Delegated Permissions
To simplify the consent process for employees, organizations can pre-approve permissions organization-wide. In Microsoft Entra -> Applications -> Enterprise Applications -> Maglr -> Permissions, these permissions can be managed.
the user.read profile permission
The following result is an example of the user.read information we get from Microsoft. Minimal company information including the GroupID's a user is a member of. With these variabels we can grant acces on e-mail or GroupID level.
{
"id": "XXXXXXX-9ac9-4d7a-8c19-XXXXXXXX",
"mail": "berry@maglr.com",
"surname": "van Elk",
"jobTitle": "CEO",
"memberOf": [
"XXXXXXX-12345-XXXX-XXXX-XXXXXXXXX",
"XXXXXXX-6789-XXXX-XXXX-XXXXXXXXX",
"XXXXXXX-10234-XXXX-XXXX-XXXXXXXXX",
],
"givenName": "Berry",
"department": "Digital Communication",
"employeeId": "12345",
"displayName": "van Elk, Berry",
"mobilePhone": null,
"@odata.context": "https://graph.microsoft.com/v1.0/$metadata#users(id,displayName,businessPhones,givenName,jobTitle,department,mail,mobilePhone,officeLocation,preferredLanguage,surname,userPrincipalName,employeeId)/$entity",
"businessPhones": [],
"officeLocation": "Breda",
"preferredLanguage": null,
"userPrincipalName": "berry@maglr.com"
}Domain Filtering by Maglr
Maglr determines the filtering for the secured domain. Based on data received from the user.read profile, users can be granted or denied access. The filtering settings can be configured after consultation. The most common filter is by @domain, where users with an email address matching the organization’s domain are granted access.
Frequently Asked Questions
Can I activate SSO on multiple domains set up within Maglr?
Yes, once the Maglr app is connected, we can create an SSO filter for multiple domains. The “consent” step does not need to be repeated; it is a one-time setup for the entire Maglr application.
Can I grant access to people outside my organization to publications behind my secured domain?
No, once secured, only Microsoft users who meet the configured filter criteria will have access to the publications.
Can I secure the dashboard itself with SSO for editors/designers in our organization?
Yes, this is possible. The authorization technically uses the same “Maglr App,” but the setup is managed within the dashboard itself. Read more.
Updated on: 20/01/2025