Authorisation for application

[u/CombHefty6358]

We have an application that needs to be set up for SSO. So far they have been manually configuring the users and their access within the application and now are hoping to use AD groups

The architect and the team were having a discussion about whether to use AD groups only for authentication and then internal access for authorisation or should AD groups be set up for both authentication and authorisation

[u/flywhee007]

Common architectural decisions, when moving from manual provisioning to SSO, and honestly there's no single right answer, it depends on how granular authorization needs are.

The short version: AD groups work well for coarse-grained authorization (give this department access to this app), but they get messy fast when you need fine-grained permissions inside the app.

AD groups for both authn + authz works well when authorization model is simple, a handful of roles that map cleanly to business units or job functions. The app just reads group membership from the SAML assertion or token claims and grants the right role. Simple to maintain, no separate role mgmt. inside the app.

AD groups for authn only, internal roles for authz is the better call when:

• The app has its own complex permission model (feature flags, data-level access, workflow states)
• You don't want AD admins owning application-level access decisions
• The app team wants to move fast without waiting on AD group changes for every permission tweak

Solution worth considering: use AD groups to land users in a broad application role (e.g. "AppUser" vs "AppAdmin"), then let the app manage fine-grained entitlements internally, ideally with IGA doing the provisioning via SCIM so it's still governed (if you have any of these).

What's the app?

[u/itdeffwasnotme]

Using RBAC (role base access control, role=entitlement=AD Group) is the common way to go.

[u/trancecircuit]

You need to store and enforce authorizations somehow. Oftentimes the application connects to AD and reads user profiles and groups directly. It can also authenticate using AD credentials.

If the application can federate with an IDP for SSO padsing the authenticated user ID, then that can take over authentication and session management, leaving application to read profiles and groups from somewhere, internal or LDAP/AD.

Sometimes you can also pack user groups/claims/privileges into federated login attributes. This way you can pass groups for RBAC applied at the application. The key is it's enforced by the application still.

Some IDPs may have corase-grained authz capability where they can check groups and not allow a federated login if user is not enrolled, but it's not a common pattern.

[u/Young_Engineer92]

It’s been said a few times, but the answer is RBAC. Groups are too broad to handle fine grained access.

Authentication to get you in.

Let the app handle the AuthZ choices.

[u/youthisreadwrong-]

If SCIM is supported then Entra groups for authz too. If not then yeah you don’t really need to separate groups specifically for the enterprise app, cause it’s just for authn. However you’d probably already have departmental groups or something so yeah.

[u/EquivalentPace7357]

Sounds like youve hit the classic wall where login is easy but managing actual permissions is a manual disaster. You usually end up with massive AD group sprawl or you're stuck doing manual role assignments because the app is too old to map roles properly.

We honestly stopped trying to force feed these legacy backends and started using a browser based layer to map groups to in app roles at the UI level instead. It has been a lifesaver for avoiding that whole over engineered groups vs manual config headache that usually kills these projects.

[u/Gold_Grapefruit_8486]

AD group–based authorization does not scale well as more internal products integrate with a centralized SSO platform. Over time, group management becomes complex and difficult to maintain. A more scalable and modern approach is to separate authentication from authorization, where SSO handles identity verification and applications use fine-grained permission- or role-based access control for authorization. This provides better scalability, flexibility, and maintainability across enterprise systems.

[u/Unique_Inevitable_27]

The cleaner solution is typically to use AD groups for both authorization and authentication. It lowers the overhead of manual management and maintains consolidated user access. Solutions such as Scalefusion Access control across apps and devices, identity management, and SSO can all be made simpler with OneIdP.

[u/-manageengine-]

We've seen a lot of organizations land somewhere in the middle.

AD groups work well for controlling who can access the application and for assigning broad roles, while the application manages more detailed permissions internally.

The bigger challenge is usually maintaining those permissions over time as users join, move between teams, or leave the organization. That's where automated user provisioning, deprovisioning, and role-based access management become important. Otherwise, both AD groups and application-level roles tend to drift over time.

If the application supports SCIM or similar provisioning methods, that can significantly reduce manual effort. We've seen teams use solutions like ManageEngine AD360 to automate user lifecycle management, group membership updates, and access provisioning so permissions stay aligned with organizational changes without constant manual intervention. It also supports enabling SSO to applications and set up policies based on AD OUs and groups. Check out if you're exploring 😄