Looking for reference to Client Application Portal

[AdrianPell]

Which version of Duende IdentityServer are you using?

7.0.8

Which version of .NET are you using?

.NET 8

Describe the bug

Not a bug - more a documentation question.

The documentation makes a passing reference to a "Client Application Portal" on this page. However, I've looked through the Quickstarts ... and indeed all the samples ... and haven't found the reference to ~/portal.

Can you point me at some more information, please?

To Reproduce

Look on this page.

Expected behavior

A link from the page to the appropriate part of the Quickstart.

[StuFrankish]

@AdrianPell - there's an example here; https://github.com/DuendeSoftware/IdentityServer/tree/main/hosts/EntityFramework/Pages/Portal

[AdrianPell]

Ah thanks - I"ll take a look!

[AdrianPell]

I've looked at that, and the functionality provided is quite limited - which is fair enough. However, I am really looking for something that might render pages differently depending on the signed-in user. In this case, that might be to only offer redirects to the appropriate services based, for example, on claims assigned to the user.

Is that something that could be possible? Currently, I'm having some difficulty getting any pages which are protected by Authorize attributes to actually render - even if there is a signed in user. I get into a login loop.

I did see the Admin area, alongside the Portal, which appears to be protected by authorization and has some very specific setup. Should I be trying something similar?

In the broader case, I'm heading toward something that might be considered a "store". Is it reasonable to co-locate that with the Identity Server, or should that be a separate application that, perhaps, uses Custom API calls to make the appropriate changes to the users (adding/removing claims, etc.)?

Apologies if this isn't the right place for this discussion.

[StuFrankish]

I've looked at that, and the functionality provided is quite limited

Agreed, it's the first time I've actually seen that myself. The premise however is pretty sound. I would like to chat to the Duende guys about the implementation however - the OpenId spec indicates that some parameters are expected, but there is no example of them being set by Identity Server in the link, or consumed by the sample clients.

However, I am really looking for something that might render pages differently depending on the signed-in user. In this case, that might be to only offer redirects to the appropriate services based, for example, on claims assigned to the user.

Yes, that's quite possible. With my current employer we have an arrangement where "role" type claims are associated with each LOB app we developed that represent the most basic access to an app. The assignment of that role claim would mean that user had access to that app and therefore our portal would only present them with a list of applications that they had been granted access to.

Additional policies in each app that then check for the presence of their specific basic access role claim provided client level access control and some optional additional logic in the authorisation step in Identity Server completed the process.

If you're interested, I wrote an article about it here https://www.stufrankish.dev/conditional-access-1/ where I covered some aspects of Conditional Access.

As all pages of our LOB applications require an authenticated and authorised user, we don't use the InitiateLoginUri property. We just send the user off to the base URL for the app and SSO picks up from there.

Currently, I'm having some difficulty getting any pages which are protected by Authorize attributes to actually render - even if there is a signed in user. I get into a login loop.

It sounds like the client session state isn't being set or maintained correctly. First thing I'd do is debug the client and see if the callback to /signin-oidc is throwing any errors and debug from there.

I did see the Admin area, alongside the Portal, which appears to be protected by authorization and has some very specific setup. Should I be trying something similar?

In the broader case, I'm heading toward something that might be considered a "store". Is it reasonable to co-locate that with the Identity Server, or should that be a separate application that, perhaps, uses Custom API calls to make the appropriate changes to the users (adding/removing claims, etc.)?

The beauty of Identity Server is its extensibility and it doesn't make up the entirety of the host application. If you want to add additional UI and management to the host that interacts with Identity Server, that's perfectly fine.

My own solutions (again, for my current employer) separated the management of Identity Server from its host and into a client application.

I don't have specific sample of my own for this, but you can check out the Admin Panel by Jan Skoruba: https://github.com/skoruba/Duende.IdentityServer.Admin

Jan's admin panel integrates into the Identity Server host and is a great all round open source option.

[AdrianPell]

Thanks Stu - that was very helpful.

I solved my login loop - a configuration error, I'm afraid! However, now I can look more into the portal/store area which looks like it will do what we need. I'm beginning to appreciate just how flexible and extensible Identity Server is!

I'm going to close this ticket as my immediate problem is solved.

[josephdecock]

Thanks @StuFrankish, this is a great answer. I'd be interested to hear your thoughts on the 3rd party initiated login. Basically we added support for the initiate_login_uri to the client model, and use it on the "portal", but since we're not really a 3rd party, there's not much use in setting the iss parameter (we ARE the issuer). Arguably, setting that would follow the spec better. If you have a use case, it would be interesting to hear about it.