sample-idserver | cloudscribe IdentityServer4 integration with multi-tenancy

sample-idserver is a JavaScript library. sample-idserver has no bugs, it has no vulnerabilities, it has a Permissive License and it has low support. You can download it from GitHub.

Each project in the solution can be run by either right clicking the project in Visual Studio and choosing "view in browser", or by opening a command window on each project folder and entering the commands dotnet restore, dotnet build, and dotnet run. This project is the sample OpenIdConnect Provider server. It is just an ASP.NET Core web application with the cloudscribe and IdentityServer4 libraries wired up and configured. The rest of the projects in the solution are sample clients and sample apis that can authenticate against the OPServer app. So this one must be running to try any of the sample clients. The OPServer project is configured with 2 "tenants", ie 2 sites in one installation, each with different users, roles, claims, clients, and apis. You can login directly to the OPServer tenants using the corresponding administrator credentials below, then a new Administration menu item will appear. Look around the administration area to see how to manage users roles, claims, clients, apis, and more or even create additional tenants if you like. Note also that the root tenant is the master tenant, administrators in the root tenant can create new tenants and manage other tenants, but administrators in Tenant2 can only manage Tenant2 and cannot create new tenants. You will only see the Site List and buttons to create new sites in the master tenant admin area. When you login directly to the OPServer it is using cookie authentication, whereas the clients use JWT authentication to talk to apis. Since the OPServer and the web clients all run on localhost it is best to use different browsers for each such as Chrome for the client, Firefox for the OPServer to keep the cookies isolated. The browser isolates cookies by host name but since localhost is always the host name for these samples there isn't isolation like you would have in a deployment to different domains. Note that while both tenants have an admin@admin.com user in administrator role, they are not the same user, users are isolated per tenant, it just so happens that we created users with the same admin@admin.com credentials in both tenants, don't let that confuse you into thinking they are the same user. All of the sample clients can authenticate using the test user credentials shown above. This client uses VueJs for the UI and authenticates against the root tenant of the OPServer, so you can use the Tenant1 test users. It calls an api in the Tenant1Api project, so to try this project you need to run OPServer, Tenant1Api, and Tenant1SpaVueJs projects. Thanks to Paul Van Bladel for contributing this sample client. This client uses no specific SPA framework for the UI, it is pure javascript and authenticates against the root tenant of the OPServer, so you can use the Tenant1 test users. It calls an api in the Tenant1Api project, so to try this project you need to run OPServer, Tenant1Api, and Tenant1PureJs projects. Thanks to Paul Van Bladel for contributing this sample client. This project just has a simple api controller, the api is consumed by the Tenant1SpaVueJs client and it validates the JWT authentication token against the OPserver project. This client uses Google Polymer for the UI and authenticates against the root tenant of the OPServer, so you can use the Tenant1 test users. In this sample the client html and js are hosted in the same project with the asp.net core api that it consumes. It has an api that validates the JWT auth token against the OPServer so the OPServer project is the only other one that needs to be running to try this sample. This client uses Google Polymer for the UI and authenticates against the root tenant of the OPServer, so you can use the Tenant1 test users. This sample is almost identitcal to Tenant1SpaPolymer, except that it consumes an API that lives in the OPServer project. This client project is an ASP.NET Core web application but it only serves static files, it doesn't have any controllers of its own. The main reason for this project is to show the flexibility that the apis and clients and the OpServer can be separate web apps or they can also be combined, ie the apis can be in the same app as the OpServer, in the same app as the client side code, or completely separate applications at different urls. This client uses Google Polymer for the UI and authenticates against the second tenant of the OPServer, so you can use the Tenant2 test users. This sample is pretty much identical to the Tenant1SpaPolymer sample except that it authenticates against a different tenant in the OPserver project. This is mainly to demonstrate the support for multi-tenancy. In this sample the client html and js are hosted in the same project with the asp.net core api that it consumes. It has an api that validates the JWT auth token against the OPServer so the OPServer project is the only other one that needs to be running to try this sample. This sample is in a separate solution by itself in the xclient folder because it requires additional Xamarin tooling and Android emulator to get it working. There is a YouTube Video that shows this sample running in the emulator. It authenticates against the root tenant of the OPServer project and consumes an api that lives within the OPServer project, so you only need the OPserver project running to test it. We used "folder" based multi-tenancy instead of "host name" based multi-tenancy for this sample just because it is easier to demo and doesn't require DNS settings to add new tenants. We used NoDb file system based storage for this demo because that way we could commit the data files to this repo and have the clients and server all setup and working for you to try. For a real deployment you should use one of the other supported storage layers such as Microsoft SqlServer, PostgreSql, or MySql. Some of the file paths used for NoDb storage and some of the Xamarin Android package names can exceed the file path limitations on Windows. Therefore it is best to clone or download this project into a very short folder path to keep the file paths as short as possible. ie I am using c:\c as my root folder for this repository and I don't run into any path too long errors, but if you put it in a deeper folder it is possible you will encounter such errors with this sample solution.