0

We got a bunch of different services (SPAs + API GW, legacy JavaEE apps, etc.). Each of those is usually ran in multiple instances (customer specific instances). The plan is to federate them under a single-sign on.

We also need to be able to authorize a single user to different set of roles in those applications - RBAC.

Eg.

  • user A can access only invoicing module of app X, is a regular user in instance Y of app Z and is an admin in app Q.

So we need to manage a set of groups (roles) to every user.

In order to keep the users manageable, the users/group storage should be central (a LDAP?). The roles in each application are specific, so it could be managed within each app.

What is the suggested architecture?

LDAP synced with a central Identity Provider?

Technology OpenID/JWT tokens? SAML claims?

So far we have experimented with a few OpenID providers. These seem to treat the authorization part (groups/roles) as a second class citizen a bit.

Improve this question

1 Answer 1

Reset to default
0

The identity providers usually do not enforce restrictions themselves. That's why your impression is correct that the authorization part is not implemented in IdPs. They rather deliver role/group/permissions information to the application (service provider, SP) so the SP can enforce authorization.

Most IdPs can access a LDAP server to retrieve user accounts, their group membership and check the user's password. Using an LDAP server has the advantage that some applications not capable of SAML, OpenID Connect, etc. might be able to directly use an LDAP server.

Managing even application-specific group membership is very helpful if you have to provide data to be examined during security audits. So I would try to keep group maintenance out of the application.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .