Hey Freddy,

I do not completely understand your question. Are applications A, B, and C external applications or IAM applications?

If you want to give users access to IAM applications, this document may help: https://docs.thinkwisesoftware.com/docs/iam/openid_provisioning
You can create various user groups to give access to different applications. Then set up provisions to decide to which user group a user belongs. 

Hi Ester, 

Don't think that's what I am looking for. Let me try to explain better. There is an application that manages clients, suppliers, partners, etc.. Let's call it A. What we would like to achieve is using the application (incl. IAM) as an OpenID provider to give access to supporting applications. 

There is a projectmanagement application (B), that uses OIDC of A to authenticate. And there is a documentation application (C) that also uses OIDC of A to authenticate. What I am trying to accomplish is that from A I can say person x, y and z from client 1 and 2 can access application B.  But not C. But person y from client 6 can access both applications B and C. 

All users have access to A with their proper roles. 

Hey Freddy,

TLDR;

I don’t think what you are asking is possible. In your scenario application A would have to take on the role of storing which users are able to access B and C meaning you would have to implement what IAM does for Thinkwise applications on your own. Consider registering OAuth/OpenID clients for B and C in IAM as well and configure custom resources to return additional claims with which you can determine if a user is actually authorized to access the resource server instead.

Full answer

I might not understand your example completely so I’m going to make some assumptions and give some background information about OpenID Connect in my answer.

OAuth 2.0 has defined a concept for:

• Authorization servers
  • These handle the authentication of the user and return access tokens that can be used to make requests to resource servers.
• Resource servers
  • These are the actual applications/APIs that validate/consume the access token and allow/deny access based on that.
  • Validation might include a check if the (assuming it is) JWT token is signed by an authorization server that the resource server trusts etc.
  • Claims within the JWT token tell the resource server what this “user” has access to parts of the API using the token.

OpenID Connect is an extra layer on top of OAuth 2.0 that basically standardizes some parts that are left up to the implementation when using “raw” OAuth 2.0. Part of this is defining an extra JWT token called the ID token and some other stuff when acting as the authorization server. E.g. it defines some pre-defined scopes, such as “openid” that can be requested.

When using the Thinkwise platform “normally” Indicium and IAM combined act as both the authorization (users stored in IAM) and resource server (applications synchronized to IAM).

There is currently no way to “scope down” access to an application within IAM. This is something we are looking into but currently the roles mechanism within IAM is what is authorizing application access after a session has been started.

For external resource servers, which I assume A, B and C are in your example, there is currently also no way to directly define scopes (besides the OpenID Connect ones) on just the initial access token.

What you can do however is create “Custom resources” in IAM and assign them to a “Client application”. In these custom resources you can define additional claims which you can assign a value per user or user group. The catch here is that these are also considered user info claims. Which means the claim values must be retrieved from the user info endpoint defined by the OpenID Connect well-known endpoints document (available at /.well-known/openid-configuration in Indicium) using the access token that was granted on login.

There is an option to always do this for a client by enabling the “Always include user info in token” setting.

So lets take a look at the example you’ve mentioned and see if I understood what you meant to convey.

• There is an IAM + Indicium setup somewhere acting as the authorization server.
• Applications A, B and C are resource servers that are “external”, meaning they are not Thinkwise applications synced to an IAM.
• Resource server A uses the IAM authorization server as an Identity Provider to provide a way for users to login.
• The authorization server has a client registration for resource server A which uses the “Authorization Code” grant type, allowing the users to login interactively etc.
• The user device, upon successful login, gets the access token which it then uses to make requests to resource server A. This can, for example, be saved as a cookie for the domain resource server A is located at.
• Upon further requests from the user device resource server A now has to, potentially, use the claims it got from the access token to authorize the request within itself.
• Resource servers B and C now want to use resource server A as an authorization server.
• This is where the problem in the scenario start.
• Resource server A must now also implement the authorization server side of OAuth 2.0/OpenID Connect.
• It could still use the IAM as an external Identity Provider as before but there might not be a point anymore to do so.
• E.g. for IAM you could also define some Azure AD/Entra tenant as an external IdP but after logging in through that a user still has to be matched with one that IAM knows about and is configured as “external”.

E.g. consider that a user might already have a session with application A.

• If they try to access resource server B it will try to ask application A if they know who this is. Because A is considered the Identity Provider/authorization server by B.
• Since the user device already has a session for application A, it will not bother asking the IAM authorization server for the user identity and potentially skip the user info step making the custom resources feature useless.
• So application A, as an authorization server either has to:
  • Manage authorization settings for resource servers B and C on its own, include client registrations etc.
  • Or still let IAM manage the users and always request the extra custom resource scope claims for B and C even if they are only logging into A. B and C still require an OAuth client registration in A to attest that it is your server making the call.
  • Detect, somehow, that session doesn’t currently have the required scopes/claims it needs and then tries to attempt to expand the user info for the session using the IAM authorization server. Which may require another login if the session on that server has expired.

I’m not even sure if the last two points are possible at all and A would still need to take care of the access token generation etc. because the IAM authorization server doesn’t actually know about B and C and those in turn cannot trust IAM for claims as the authorization server they have been configured with is A, not IAM.

All of them also require that you have full control over how application A is built.

A much simpler option would be to just have A, B and C all act as resource servers with their own client registration in IAM. You could then define custom resources for each to signal whether a user (group) actually has access to your external application. Assuming of course that you have enough control over A, B and C to validate the claims that get sent back from IAM.

If I misunderstood what you are asking let me know.

Hi ​@Tim Waalewijn. First of all, thank you very much for the elaborate answer. I understand that my scenario will not work at the moment, but maybe in the future. Because it will put a TW application in the middle and will gain more 'value'. 

Let me just try to give a bit more detail to find out if it fits within what you call "scope down". 

The scenario is that application A is the main application build with TW and is connected to Entra as an external identity provider. If you exists in Entra you can login to App A and depending on your role you can administer the clients, partners and suppliers. 

Applications B and C are function specific applications that have the ability to use OIDC for authentication. (FYI - the support in B and C is limited in areas of extra claims and translating these claims in to specific authorization groups.) 

So scenario at hand:

Application B is a project management application and there is a project with client X. Within application A I will have client X with some employees. There I want to say that certain employees have access to Application B. In the simplest form. Fine grained authorization is managed in B. 

What I want to achieve is that an employee of Client X logs in on App B using OIDC. Then App A will tell App B that user (email) is known for access to Application B. 

The challenge here is, I guess, that from App A I need to add this employee as a User in the IAM into a specific group or tenant of such. I know this can be done. The key point will be to be able to steer the registered client application B to only look at users in this specific group/tenant. As its existence in this group/tenant will confirm the allowed access.