Orchardcore: Decouple the OpenID server/validation features

[hamdiRuwiss]

this returns the access token

then when sending the request i get redirected to login page the request doesn't get
picked by openid auth

this is the settings

with allow password flow checked

[kevinchalet]

Is your API action decorated with [Authorize(AuthenticationSchemes = "Bearer")]?

What do the logs say?

[hamdiRuwiss]

only [Authorize]

[hamdiRuwiss]

thank you this solved my issue

[kevinchalet]

only [Authorize]

Orchard uses cookies authentication by default (as long as you enable the Users module). To use token authentication, you must be explicit and say you want to use the "Bearer" scheme.

[hamdiRuwiss]

do you have any idea how i could enable the openid for tenants and make the default site as identity server

[kevinchalet]

I'm not sure I understand your question. Care to elaborate?

[hamdiRuwiss]

ok i enabled different tenant apps in orchard when i enable openid for the site in the settings i set the Authority to the default site and this cuased the authorization code and implicit flows to redirect me to the log in page for the main site which i enabled the openid but the users actually live in diffrent database per tenant so if possible it would be nice for the tenants to use the main site as identity service
and for them to enable them as applications only

[hamdiRuwiss]

problem is that the users live in different databases when the spec for identity service is to be the one user store i hope you get what i mean

[kevinchalet]

@sebastienros will correct me if I'm wrong, but I don't think there's currently an (easy) way to share databases between tenants since pretty much everything is isolated (that's generally a good thing from a security perspective).

One thing we'll enable in the near future is the ability to separately/selectively enable the OIDC server/token validation features, so you'll be able to enable the OIDC server in your main tenant and the token validation in a second tenant. Would that fit your scenario?

[hamdiRuwiss]

exaaactly

[hamdiRuwiss]

as of now i have to enable openid identity service for every tenant which i think is duplicate

[hamdiRuwiss]

and there is no point in adding those tenants as apps in the Audiences field of the settings

[sebastienros]

Correct. The idea is be to be able to use one tenant for authentication. Which is not the case right now.

[hamdiRuwiss]

because for the mobile and web flows its going to redirect me to the main site log in page which will look for users in that database while they have their own database
unless you know a workaround for this i would be thankful to know

[jtkech]

Maybe out of context but just some thoughts on the fly and as i remember, so not sure at all.

So, tenants are isolated, they can consume tenant or app level services, and now in its startup a tenant can replace a service registered at the app level for its own isolated usage.

To share things we could have app level services (with different names) but maybe a problem for doing special things that need a shell context. So, i thought about the ability of a module, as soon as a tenant uses it, to register itself and once a kind of "static" services at the app level, so they can be consumed by all tenants. Such a service would need to be executed in the context of a Super tenant, maybe the Default.

[sebastienros]

That a solution and we already support it, look at IOrchardHost for instance.

But I think this need is mostly needed for authentication, never the case out of this example, but very common request. I think a good solution would be to support authentication from a different tenant using APIs, and use a bearer token to send on the other tenants. This way everything remains isolated like today. We just need a custom module for auth that would be configured with the url of the service (on another tenant). Single Sign On.

Another solution would be to be able to share a database or tables with. We would still need another module but all tenants would read the same tables. They would then share an IStore to manage the items. And the module would be responsible for its own migrations.

But I prefer the delegated auth solution.

[jtkech]

I like the API solution 👍

That reminds me a system i did with distributed IO modules (little PLCs with their own program) without any master one. Sometimes it was not so easy to solve problems without tending to introduce a master, but we always solved problems by letting them communicate. I did it 20 years ago, too soon for such things ;)

[kevinchalet]

@sebastienros making a tenant act as the server and the other ones as OIDC clients or API/resource servers is really tempting and ideal from a security perspective (because, as you said, everything is perfectly isolated).

That said, it's definitely not a trivial task: we'd need to update the OpenID to use the OIDC client (for tenants that need SSO) and the aspnet-contrib introspection handler (for tenants that want to validate opaque tokens).

[kevinchalet]

A few words about my progress:

• The server/token validation features of the OpenID module have been completely decoupled.

• The server feature now maintains its own private JWT/validation handler instance for the userinfo API endpoint. This way, you don't have to enable the token validation feature when using the authorization server feature.

• You can now configure the validation feature to transparently use the server configuration of another tenant (which has the authorization server feature enabled). We do that by retrieving the IServiceProvider associated with the server tenant and resolving the services we need in this context (e.g IDataProtectionProvider).

• You can also configure the validation feature to validate tokens issued by a remote OIDC server issuing JWTs like Azure B2C or any other server.

• The JWT validation feature was reworked to avoid making a loopback HTTP discovery call when the authorization server is a tenant (which is not ideal for containerized deployments). Instead, we retrieve the issuer/signing key directly from the tenant's settings.

• You can now use the management UI to manage existing OpenIddict (i.e non-Orchard) deployments.

• A new DataProtection module takes care of replacing IDataProtectionProvider by a tenant-aware instance.

• A new Antiforgery module takes care of overriding the default antiforgery cookie name to use tenant-specific names, exactly like what the Users module does for the orchauth cookies.