3

We need to integrate SSO to allow already-logged-in users of our system to login to a third-party web hosting provider. The provider requires OIDC for SSO, but they expect all our users to already have an identity provider (IdP). We already support SSO into our app for Google, Microsoft, and Okta users, so we are not entirely ignorant of OIDC. But the direction we have implemented is the opposite, Third-Party IdP --> Us, not Idp (Us) --> Third-Party.

As our system is 20+ years old, the majority of our user base is in our own custom credential store designed pre-OIDC. We are not an IdP. Also, we support only .NET Framework 4.8.1. (i.e. not Core/5+). What would be the easiest way to proceed? The third party requires:

  • a client ID (no problem)
  • a client secret (no problem)
  • a config URL/well-known OIDC endpoint (This is a problem - it requires a bunch of other endpoints internally.)

I saw this post from 2012, and it's almost exactly the same situation as ours, but the DotNetOpenAuth repository has been archived since 2019. There is also the IdentityServer project, but IdentityServer3 seems to be the most recent version that still supports .NET Framework (not Core), and it hasn't been updated since 2018.

Can anyone suggest a currently-maintained .NET Framework (not Core/5+) library that can implement an OIDC IdP?

Jordan Rieger
  • 3,025
  • 3
  • 30
  • 50

1 Answers1

1

I always aim to explain the architecture in term of thinking backwards from APIs. But let me know if you think I've misunderstood anything.

AUTHORIZATION SERVER

The preferred architecture is for your apps and APIs to only interact with an AS, for the simplest code and best capabilities. The AS issues access tokens whose scopes and claims you can lock down, to best protect your business data.

Also, users can potentially sign into your client applications in many ways, eg Google IDP, Microsoft IDP, WebAuthn, other organization, depending on how you configure the AS.

FEDERATED LOGINS

A federated login flow across organizations, where all parties use OIDC, works like this:

  • Client runs a code flow to redirect to AS1

  • AS1 will redirect to AS2 using another code flow. From AS2's viewpoint, AS1 is just another client. AS2 can use all of its existing login methods, or alternatively act as a simple IDP.

  • Client is issued tokens by AS1 - the one that protects its business data.

SUMMARY

In your case you seem to lack the authorization server role, which is a prerequisite to do this type of integration in the best way.

If your apps and APIs used one, and it supported the correct behaviours, your AS would implement the AS2 role above for the use case you describe. An AS should be able to integrate with existing user and credential stores.

To integrate an IDP or AS, you would need to look into those that support OIDC and also integration with existing data sources, eg docker based. A solution is not limited to .NET, since you will just use its endpoints. It is against SO guidelines to recommend providers though.

Gary Archer
  • 22,534
  • 2
  • 12
  • 24
  • Thanks Gary. While I agree that our solution need not be limited to .NET, in practice since it must integrate with our existing user stores (which are wrapped by existing .NET business logic) a .NET solution would be the most practical and would avoid us having to build more API layers. So as part of a comment and not an answer, could you weigh in on IdentityServer3 vs DotNetOpenAuth, if you have experience with either of those? – Jordan Rieger Apr 27 '23 at 20:49
  • Neither feel right to me. Eg in the past I worked in a .NET company with no real Java knowledge. We ended up choosing a Java based product and calling its endpoints over HTTPS. We used JDBC to integrate with SQL Server, and LDAP to integrate with Active Directory. In terms of next steps, do some spikes to see if your candidate systems meet requirements. That is what I did. – Gary Archer Apr 27 '23 at 20:57
  • Man, that sounds so convoluted. Running a dedicated IdP in another framework and calling its HTTPS endpoints sounds straightforward, except that its endpoints need to call back to our existing user data stores, call our business logic, etc. But I guess that is why we have jobs in IT. Everything is a convoluted mess! – Jordan Rieger Apr 27 '23 at 21:00
  • But there is no code - just a connection string. It should be about interoperability and simplicity when done well. You may find a .NET one that does what you want. This stuff is architectural also - getting the foundations right - and can involve other stakeholders. – Gary Archer Apr 27 '23 at 21:06
  • Well there needs to be business logic code to determine if the user being looked up is valid to expose via this IdP (i.e. not necessarily just a simple SQL query over a connection string.) And that code is best written in .NET to maintain consistency with our existing business logic code. We don't want to expose every user in our existing store. We're not trying to convert our whole user store over to OIDC, only enable SSO for specific users who we want to integrate with this third party. – Jordan Rieger Apr 27 '23 at 21:39
  • 1
    A common pattern is to expose custom logic via API endpoints that the AS calls at the time of authentication or token issuance. This can involve your business logic in end to end flows, when this type of extensibility is supported. It is preferred to changing and recompiling the core AS implementation. Out of interest, on .NET I believe that [OpenIddict](https://github.com/openiddict/openiddict-core) is popular, but whether it has these behaviours or meets your requirements I do not know. – Gary Archer Apr 27 '23 at 22:04
  • Interesting, will check out OpenIddict. Thanks Gary. – Jordan Rieger Apr 27 '23 at 22:08