Partner Portal Federation Without Breaking Role Assignments
A B2B warranty-claims portal runs on OutSystems and serves 1,350 partner technicians from 42 companies. Today it uses built-in authentication; each partner company maintains its own user list, and the help desk handles 60–80 password resets a week. The business wants single sign-on through the partners' Microsoft 365 tenants, but the partners range from enterprises with Azure AD to small shops with no IdP. The portal has four roles: Technician, Supervisor, Auditor, and PartnerAdmin. Role assignments are currently maintained by an internal operations team in the Users screen. A pilot with one partner failed because users authenticated but landed on an empty dashboard: their roles were not mapped, and a few users had duplicate accounts from the old local login. Go-live is in six weeks; the security team will not approve a shared local password fallback for all partners.
1. Recommend an authentication design for partners with Azure AD and partners without an IdP. Justify the trade-offs and list the go-live conditions.
Read the worked answer
Use a single federation broker, such as the company's Azure AD B2B tenant or an Okta hub, as the only SAML 2.0 or OpenID Connect identity provider configured in the OutSystems app. Partners with Azure AD federate to the broker; small partners get broker-managed accounts with MFA and self-service reset. This avoids configuring many direct IdPs in one app and gives one consistent assurance level, but it adds broker cost and a dependency. Do not keep a shared local password fallback for all partners; keep at most a controlled break-glass local admin account. Go-live conditions: signed metadata exchange, claim mapping for a stable user ID and groups, just-in-time provisioning, deterministic role mapping, duplicate-account cleanup, tested logout, and a rollback plan. Verify that the chosen platform edition supports the protocol and the partner connections through the broker.
2. The pilot users authenticated but had no roles. Explain the cause and how to make role assignment deterministic and auditable.
Read the worked answer
Authentication proves identity; it does not grant authorization. If the app's roles live in local User/Role entities and the login flow never maps IdP groups or claims to those roles, a new federated user is created with no roles, so the dashboard is empty. Hiding the dashboard is not the issue; the server-side role check fails closed. Map IdP groups to OutSystems roles in one place, preferably during provisioning or login, and keep the mapping table under change control. Use a unique immutable identifier such as the IdP object ID, not email, to link accounts and avoid duplicates. Default to no role, not Technician, and alert on unmapped groups. Audit every role change with actor, source, and timestamp. Test with real claims from each partner class, including a user who changes groups.
3. What should happen to the 60–80 weekly password resets during and after migration?
Read the worked answer
Do not preserve the current local-password habit for all partners. For federated partners, resets move to their IdP; the help desk should stop resetting those accounts after cutover. For partners without an IdP, the broker should provide self-service reset and MFA, with an admin-assisted path for exceptions. Keep a small break-glass local account, restricted to named administrators, with strong rotation and monitoring, not a shared fallback. Run a grace period where local login still works but is loudly deprecated, then disable it; measure reset volume and failed logins to catch partners who are not ready. Communicate the cutover date and support path before disabling.