IdentityServer/AppPortal Arch Roadmap

Executive Summary 

Catalis IdentityServer is a cloud-based authentication server based on the OpenID Connect and OAuth 2.0 framework. At its core is Duende IdentityServer which is officially certified by the OpenID foundation (OIDF) the standards body that develops identity and security specifications. Catalis has taken full advantage of the flexibility and extensibility of the IdentityServer product to not only customize the UI of IdentityServer, but also build upon it three modern web-based applications. The first application provides a user interface to the system management functionality of IdentityServer and is referred to as IdentityServer Admin (Admin). The second application provides product management, tenant management, and user management and is called the App Portal. The third application IdentityServer API (API) is the shared back-end that is used by both Admin and App Portal. These four applications: IdentityServer, Admin, App Portal, and API, have been in production use by AutoMon since early 2018.  

The Catalis IdentityServer application was originally based on the IdentityServer open-source project started by Dominick Baier and Brock Allen. The two eventually made a fork of their open-source project and started the company Duende. Catalis has since purchased a licensed version of IdentityServer from Duende and we are in the process of upgrading to the latest version. The product proved to be so stable in production that AutoMon had been neglecting version updates over the years. The AutoMon IdentityServer production environment was last updated on 4/4/2023, but this update was only through v3.1.2, which was released on 7/5/2020. Duende, however, has continued releasing regular updates, the last of which was v7.0.1 released on 2/9/2024. 

This document outlines the architectural work necessary to bring IdentityServer current and also to enhance the Admin, App Portal, and API applications to bring the most value to all products in the vertical. 

Current Architecture 

The Catalis IdentityServer information below details the technologies used in IdentityServer,  Admin, and App Portal and also describes the environment in which they are deployed. 

IdentityServer technology stack 

Front-end 

• Microsoft .NET v7 with C# v11 

• http://ASP.NET MVC Razor Pages 

• Authentication: 

  • OpenID Connect (OIDC): industry standard authentication protocol 

  • JSON Web Tokens (JWT): industry standard security token format 

  • Microsoft http://ASP.NET Core authentication libraries – latest encryption/decryption/verification libraries provided by Microsoft 

Back-end 

• Microsoft .NET v7 with C# v11 

• Microsoft Entity Framework 

• Authentication: 

  • OpenID Connect (OIDC) 

  • JSON Web Tokens (JWT) 

  • Microsoft http://ASP.NET Core authentication libraries 

  • Database: Microsoft SQL Server 

IdentityServer deployment architecture 

• 1 Azure App Service  

• 1 Azure SQL Server 

• 1 Azure Blob Storage Account 

Admin technology stack 

Front-end  

• Angular v14: UI framework developed by Google 

• Angular Material v14: Prebuilt UI Components developed for use in Angular 

• Sass CSS v1.58: Library used to style HTML elements 

• Authentication: 

• OpenID Connect (OIDC) 

• JSON Web Tokens (JWT) 

• oidc-client.js library 

Admin deployment architecture 

• 1 Azure App Service 

App Portal technology stack 

Front-end  

• Angular v14: UI framework developed by Google 

• Angular Material v14: Prebuilt UI Components developed for use in Angular 

• Sass CSS v1.58: Library used to style HTML elements 

• Authentication: 

• OpenID Connect (OIDC) 

• JSON Web Tokens (JWT) 

• oidc-client.js library 

App Portal deployment 

• 1 Azure App Service 

API technology stack 

Back-end 

• Microsoft .NET v6 with C# v10 

• Command Query Responsibility Segregation (CQRS): Separates the concerns of the Command (create, update, and delete) operations from the Query(read) operations 

• Dapper: An object relational mapping (ORM) library which simplifies the create, read, update, and delete (CRUD) operations on the database by automatically mapping database parameters and data results to C# objects 

• Fluent Validation: A library which allows developers to easily implement complex validation rules on all data sent to the API 

• MediatR: an in-memory bus which implements a publisher/subscriber (Pub/Sub) used to loosely couple the API layer to the Application Layer and handle intra-domain events 

• Azure Service Bus:  Robust message bus functionality used to communicate with external systems such as Ce Sync 

• Authentication: 

• OpenID Connect (OIDC) 

• JSON Web Tokens (JWT) 

• Microsoft ASP.NET Core authentication libraries – latest encryption/decryption/verification libraries provided by Microsoft 

API deployment architecture 

• 1 Azure App Service 

• 1 Azure Service Bus 

Assessment of system scalability, performance, and reliability 

• Scalability: All Azure App Services can be scaled in real time to handle increased workloads. 

• Application / Database Performance: The Production environment handles over 1.3 million requests per day with an average response time of 4 milliseconds. 

• Application Reliability: IdentityServer App Service could be deployed to a different Azure Government Region in case of an outage; however, this is currently a manual process. 

• Database Reliability: IdentityServer database is not part of a failover group. 

Identification of architectural bottlenecks and pain points 

• Hardcoded product names / icons: Because the application was initially designed to host AutoMon products, some of the product names and icons are hardcoded into the application instead of being derived from a database.  

• Modularity / learning curve: The application could technically be viewed as 5 separate projects IdentityServer front-end, IdentityServer back-end, Admin web app, App portal, API. Thus, there is a longer learning curve when bringing new developers on board. 

Evaluation of security posture 

• Authentication / Authorization: The Admin and App Portal apps store JWT Access Tokens client side in the browser. This method of storing tokens is now considered obsolete and the industry recommends switching to using a back-end for front-end (BFF) security architecture. 

• Back-End security: Each request to an API Endpoint must contain a User Access Token which is validated by the API layer before being processed by the Server. In addition to a valid User Access Token, the user’s account must have the proper permissions assigned withing the AIMS system before being processed by the Server. 

• Sensitive Information: IdentityServer stores all sensitive information in an Azure Key Vault and accesses this information in an encrypted manner at runtime as necessary. 

• Automatic Key Management: IdentityServer has introduced the ability to automatically manage signing keys. This feature will be deployed in stages throughout the later part of 2024. 

Review of development and deployment processes 

•  Development 

  • Each development task is performed on a fork of the development branch 

  • When a developer completes a feature, the feature is deployed to the test environment for testing and UI/UX approval 

  • Only after successful testing and UI/UX approval is a PR created for the changes 

  • A PR is created by the developer for review by senior team members 

  • Only after approval of the PR is the feature merged back into the development branch 

  • Testing is performed on the development branch 

  • After testing has passed on the development branch, this branch is merged into the master branch for the next release 

•  Deployment

  • A releasable version (frozen code) is created each time code is checked into the master branch. Releases can also be manually created and manually labeled with a version at any time. 

  • IdentityServer, Admin, and API are deployed as a group into the test environment, preview environment, and the production environment with 1 click. 

  • App Portal can be deployed into the test environment, preview environment, and the production environment with 1 click. 

  • Production releases can be deployed multiple times to the preview environment to ensure compatibility before the production environment is updated.

Vision and Goals 

This section covers some issues in the IdentityServer, Admin, App Portal system. The following items describe those issues and include steps to resolve the issues. 

Easier Product Management

Currently the process for adding new products to IdentityServer requires manual database scripting. Work should be done to allow this process to be completed in the UI. 

Passkey/Passwordless Authentication

Implement authentication methods outlined by the FIDO Alliance for passkey/passwordless access to systems. Some examples of tools currently being utilized to enable passkey solutions include Apple Passkey, Windows Hello, Microsoft Authenticator, Google Authenticator, etc. Research implementing passkey/passwordless authentication to IdentityServer. 

Security

As mentioned previously the User Access Tokens are stored in plain text client side. Admin and App Portal should be enhanced to implement the Duende Identity Server BFF Framework. 

Automated Testing

Outdated packages

Architectural Principles 

Following are industry established architectural principles to be followed when designing new functionality for the application:  

• Modularity: Compose discrete, interchangeable modules with well-defined interfaces, promoting reusability, maintainability, and ease of understanding. 

• Scalability: Architect features to scale horizontally and vertically to accommodate growing user bases and increased workloads, leveraging distributed systems and efficient resource utilization. 

• Loose Coupling: Minimize dependencies between components to reduce the impact of changes and facilitate independent development, testing, and deployment of modules. 

• High Cohesion: Ensure that each module or component has a clear, focused purpose and functionality, promoting better maintainability, testability, and understanding of the codebase. 

• Separation of Concerns: Divide the application into distinct layers or components, each responsible for a specific aspect of functionality (e.g., presentation, business logic, data access), to improve modifiability and clarity of design. 

• Security by Design: Integrate security measures and best practices into the architecture from the outset, including authentication, authorization, encryption, and secure communication protocols, to protect against potential threats and vulnerabilities. 

• Performance Optimization: Architect the application to be performant by employing efficient algorithms, data structures, caching mechanisms, and optimization techniques to minimize latency, maximize throughput, and optimize resource utilization. 

• Flexibility and Extensibility: Design the application to accommodate future changes and enhancements by adopting flexible, extensible architectures and design patterns that allow for easy integration of new features, modules, and technologies. 

• Resilience and Fault Tolerance: Build the application to withstand and recover gracefully from failures, errors, and unexpected events by implementing fault-tolerant mechanisms, redundancy, graceful degradation, and automated recovery processes. 

• Testability: Ensure that the application is designed for ease of testing, with clear separation of concerns, modular architecture, and support for automated testing frameworks and tools to facilitate comprehensive testing and validation of functionality. 

• Simplicity and Minimalism: Strive for simplicity in design and implementation, favoring straightforward solutions over overly complex ones, to reduce cognitive overhead, minimize technical debt, and improve maintainability. 

• Adaptability to Change: Architect the application to be adaptable and responsive to changing business requirements, technological advancements, and user feedback, enabling iterative development, continuous integration, and delivery practices. 

Key Initiatives and Timelines 

This section describes major architectural initiatives planned to minimize technical debt and address the shortcomings defined in the vision and goals section of the document. 

Initiative 1: Update Catalis IdentityServer in Production 

• Description: Currently the IdentityServer version in production v3.1.2 and should be updated with the version that is currently in the Test and Preview environments which is v6.3.8.  

• Objective: Complete testing in the Preview environment and ready a version update for Production. 

• Timeline: Q1 2024 - Q2 2024 

• Key Milestones:  

  • February Q1 2024: Test environment was successfully update with v6.3.8  

  • February Q1 2024: Preview environment was successfully update with v6.3.8 

  • March Q1 2024: Build a new WSFED Identity Provider in the Preview environment to ensure WSFED authentication works properly 

  • March Q1 2024: Complete successful login with Pierce County, WA (WSFED Tenant) user 

  • March Q1 2024: Complete successful login with Washington County, NY (OIDC Tenant) user 

  • April Q2 2024: Update Production Environment to v6.3.8. Update includes Stage 1 of 3 for migrating to Automatic Key Management (AKM) 

  • May Q2 2024: After 2 weeks deliver Stage 2 of 3 for migrating to AKM 

  • May Q2 2024: After 2 weeks deliver Stage 3 of 3 for migrating to AKM 

Initiative 2: Update IdentityServer to replace all instances of AutoMon branding with Catalis 

• Description: As IdentityServer was initially designed solely for use by AutoMon, some emails generated by IdentityServer (Account Created Email, Update Password Email, etc.) and some UI screens still reference AutoMon instead of Catalis. NOTE: This must be done before a Jury or Coral Go-Live 

• Objective: Update the application from AutoMon to Catalis 

• Timeline: Q2 2024 – Q3 2024 

• Key Milestones:  

  • April Q2 2024: Work with product owners from other products to develop new email language 

  • May Q2 2024: Implement changes and deploy to test environment for initial testing 

  • June Q2 2024: Integrate issues found into ongoing Sprints 

  • June Q2 2024: Update preview environments for acceptance testing 

  • July Q3 2024: Push changes to Production 

Initiative 3: Update App Portal Front-end Framework and remove hardcoded icons 

• Description: App Portal is currently running Angular v14 in Production which has been out of Active Support since 11/18/2022 and out of Security Support since 11/18/2023. The App Portal also has a hardcoded list used for displaying icons instead of pulling the icons from the database. This application also has hardcoded instances of “AutoMon” branding 

• Objective: Update to Angular v16, remove flex-layout library, remove products from code 

• Timeline: Q2 2024 – Q3 2024 

• Key Milestones:  

  • May Q2 2024: Update application to Angular v16 

  • May Q2 2024: Deploy to Test Environment for initial testing 

  • May Q2 2024: Integrate issues found into ongoing Sprints 

  • June Q2 2024: Deploy to Preview Environment for acceptance testing 

  • July Q3 2024: Deploy to Production environment 

Initiative 4: Update API .NET Version 

• Description: API should be updated to .NET 8 and tested with the latest libraries from Duende. NOTE: This is not required for a Jury or ORMS Go-Live 

• Objective: Update the API to .NET 8. 

• Timeline: Q2 2024 – Q3 2024 

• Key Milestones:  

  • April Q2 2024: Update to .NET 8  

  • April Q2 2024: Deploy to Test Environment 

  • April Q2 2024: Integrate issues found into ongoing Sprints 

  • May Q2 2024: Deploy to Preview Environment 

  • July Q3 2024: Deploy to Production environment 

Initiative 5: Update Admin Front-end Framework 

• Description: Admin is currently running Angular v14 in Production which has been out of Active Support since 11/18/2022 and out of Security Support since 11/18/2023.  

• Objective: Update to Angular v16 and remove flex-layout library. NOTE: This front-end is not accessed by customers so updating is not a high priority. 

• Timeline: Q3 2024 – Q4 2024 

• Key Milestones:  

  • August Q3 2024: Update application to Angular v16 

  • September Q3 2024: Deploy to Test Environment for initial testing 

  • September Q3 2024: Integrate issues found into ongoing Sprints 

  • October Q3 2024: Deploy to Preview Environment for acceptance testing 

  • November Q3 2024: Deploy to Production environment 

Initiative 6: Update Catalis IdentityServer to Duende IdentityServer v7.0.1 

• Description: IdentityServer back-end should be updated with the latest libraries from Duende. This requires an update to .NET 8. 

• Objective: Update the Duende IdentityServer packages to v7.0.1 with .NET 8. 

• Timeline: Q4 2024 – Q1 2025 

• Key Milestones:  

  • October Q4 2024: Update to IdentityServer v7.0.1 

  • November Q4 2024: Deploy to Test Environment for initial testing 

  • November Q4 2024: Integrate issues found into ongoing Sprints 

  • December Q4 2024: Deploy to Preview Environment for acceptance testing 

  • January Q1 2025: Deploy to Production environment 

Initiative 7: Implement Passkeys/Passwordless Authentication 

• Description: The industry is quickly adopting passkey/passwordless authentication using tools such as Apple Passkey, Windows Hello, Microsoft Authenticator, and Google Authenticator. Research and implement a solution using these technologies into Identity Server.  

• Objective: Update the API to .NET 8. 

• Timeline: Q4 2024 – Q1 2025 

• Key Milestones:  

  • November Q4 2024: Research existing implementations of Passkeys with IdentityServer 

  • November Q4 2024: Implement Passkeys for internal users with a sample product 

  • December Q4 2024: Deploy to Test for initial acceptance testing  

  • December Q4 2024: Integrate issues found into ongoing sprints 

  • January Q1 2025: Deploy to preview environment for acceptance testing 

  • January Q1 2025: Deploy to production environment 

Dependencies and Risks 

Identification of dependencies between architectural initiatives and potential risks (e.g., resource constraints, technology adoption challenges) that could impact successful implementation. 

• Major Production update from IdentityServer v3 to v6 requires significant testing in Preview environment to prevent outages. This includes setting up a new domain in Azure with WSFED authentication for testing. 

• Updating all 4 products (IdentityServer, Admin, App Portal, and API) and testing them together will require significant effort 

• Angular Flex-Layout library usage will affect a large percentage of the HTML files in Admin and App Portal applications 

• Timelines were created assuming Bradey Stephens and Daniel Gerard are both working near full-time on all initiatives 

Resource Allocation 

1. Update Catalis IdentityServer in Production 

   1. Resource Allocation: Bradey, Daniel

   2. Training Needs: Review all changes made to source for IdentityServer v6.3.8 

2. Update IdentityServer to replace all instances of AutoMon branding with Catalis 

   1. Resource Allocation: Bradey, Daniel 

   2. Training Needs: None 

3. Update App Portal Front-end Framework and remove hardcoded icons 

   1. Resource Allocation: Bradey, Daniel 

   2. Training Needs: Review resources for removing Angular Flex-Layout 

4. Update API .NET Version 

   1. Resource Allocation: Bradey, Daniel 

   2. Training Needs: Review .NET 8 documentation / C# 12 language enhancements 

5. Update Admin Front-end Framework 

   1. Resource Allocation: Bradey, Daniel 

   2. Training Needs: None 

6. Update Catalis IdentityServer to Duende IdentityServer v7.0.1 

   1. Resource Allocation: Bradey, Daniel 

   2. Training Needs: Review documentation for Blazor 

7. Implement Passkeys/Passwordless Authentication 

   1. Resource Allocation: Bradey, Daniel 

   2. Training Needs: Review specifications for Passkeys 

Governance and Oversight 

 Purpose 

This plan establishes a clear framework for software development and architecture governance within the Jury V2 project. This framework will guide the design, development, and maintenance of our systems, ensuring consistency, quality, and alignment with our business objectives. 

Scope 

This plan covers all aspects of software development and architecture for the Jury V2 product, including design principles, development processes, architectural standards, and governance mechanisms. 

Architecture Vision 

Strategic Goals 

• Enhance user experience and accessibility. 

• Ensure scalability and performance. 

• Maintain security and compliance standards. 

• Facilitate integration with external systems. 

Key Principles 

• Modularity: Design systems as a collection of independent, interchangeable modules. 

• Interoperability: Ensure systems can exchange and use information seamlessly. 

• Scalability: Design systems to handle increasing loads gracefully. 

• Security: Embed security considerations into every aspect of the architecture. 

Development Process 

Agile Methodology 

• Sprints: Develop features in short, iterative cycles (sprints).  Sprints will last 2 weeks. 

• Backlog Management: Maintain a prioritized list of user stories and tasks. 

• Continuous Integration/Continuous Deployment (CI/CD): Automate testing and deployment processes. 

Quality Assurance 

• Code Reviews: Conduct regular code reviews to ensure code quality and adherence to standards. 

• Automated Testing: Implement a comprehensive suite of automated tests (unit, integration, and end-to-end). 

• Performance Monitoring: Continuously monitor system performance and address any issues proactively. 

Architecture Governance 

Architecture Review Board (ARB) 

Establish an ARB comprising key stakeholders to oversee architectural decisions. The ARB will: 

• Review and approve architectural designs and changes. 

• Ensure alignment with strategic goals and compliance with standards. 

• Resolve architectural conflicts and issues. 

Standards and Guidelines 

Develop and maintain a set of architectural standards and guidelines, covering: 

• Coding standards 

• Security protocols 

• Data management practices 

• Integration patterns 

Compliance and Auditing 

Implement mechanisms to ensure compliance with architectural standards and guidelines, including: 

• Regular audits of code and architecture 

• Automated tools to enforce standards 

• Reporting and addressing non-compliance issues 

Communication Plan 

Meetings 

Architecture Project Kick-off Meeting: 

Frequency: At the project initiation phase. 

Attendees: All stakeholders. 

Purpose: Introduce the project, its goals, roles, and expectations. 

Bi-Weekly Status Meetings: 

Frequency: Every other [Specify Day] at [Specify Time]. 

Attendees: Software Development. 

Purpose: Discuss progress, address issues, and plan for the upcoming sprint.  Decide if changes are needed to architectural plan. 

Sprint Planning Meetings: 

Frequency: At the beginning of each sprint. 

Attendees: Software Development, Product Management, and Project Management teams. 

Purpose: Define sprint goals, prioritize tasks, and align on the scope. 

Sprint Review/Demo Meetings: 

Frequency: Every other [Specify Day] at [Specify Time]. 

Attendees: Software Development, Implementation, Product Management, and Project Management teams. 

Purpose: Demonstrate work that has been completed, discuss sprint goals and what was completed.  Architecture work will be part of normal sprint demo time. 

Communication Tools 

Roles and Responsibilities 

Escalation Process 

In case of unresolved issues or conflicts, the following escalation process will be followed: 

Reporting 

Regular status reports will be shared with all stakeholders, summarizing progress, issues, and action items. These reports will be distributed after each bi-weekly status meeting. 

Metrics and KPIs 

Scalability: Measure the system's ability to handle increased workload or growth in data volume, users, or transactions. 

Reliability: Evaluate the system's ability to perform consistently and predictably under varying conditions. 

Maintainability: Assess how easily the system can be maintained, updated, and enhanced over time. 

Interoperability: Evaluate the system's ability to work seamlessly with other systems or components. 

Compliance: Ensure that the system meets regulatory, legal, and contractual requirements. Also ensure the security ticket backlog is regularly mitigated. 

Review and Update Process 

To ensure that the architectural roadmap of the Jury V2 product is regularly reviewed and updated to align with evolving business needs, incorporate emerging technologies, and address feedback from stakeholders. 

1. Initiation: The review and update process is initiated quarterly, triggered by the end of each quarter. 

2. Stakeholder Identification: Identify key stakeholders who will contribute to the review and update process, including product managers, implementation personnel, developers, QA, architects, and any other relevant parties. 

3. Feedback Collection: 

   1. Stakeholders provide feedback on the current architectural roadmap, highlighting areas for improvement, emerging trends, and business needs. 

   2. Feedback can be collected through surveys, interviews, and workshops. 

4. Review Meeting: 

   1. A review meeting is scheduled with key stakeholders to discuss the feedback and assess the current architectural roadmap. 

   2. The meeting agenda includes a review of the feedback, identification of key areas for update, and prioritization of changes. 

5. Update Proposal: 

   1. Based on the review meeting, a proposal is drafted to update the architectural roadmap. 

   2. The proposal includes a summary of feedback, proposed changes to the roadmap, rationale for the changes, and estimated impact on the product. 

6. Approval Process: 

   1. The update proposal is presented to the ARB and development management for approval. 

   2. The ARB and development management team evaluates the proposal based on alignment with business goals, feasibility, and resource availability. 

7. Implementation Planning: 

   1. Once approved, an implementation plan is developed detailing the steps, timeline, and resources required to implement the updates. 

   2. The plan includes the previous communication plan to inform stakeholders about the upcoming changes. 

8. Implementation: 

   1. The updates to the architectural roadmap are implemented according to the plan. 

   2. Developers and architects collaborate to ensure that the updates are integrated smoothly into the development process. 

9. Monitoring and Feedback: 

   1. Post-implementation, the updated roadmap is monitored closely to assess its impact on the product. 

   2. Feedback is collected from stakeholders to evaluate the effectiveness of the updates and identify any further improvements needed. 

10. Documentation: 

    1. All updates to the architectural roadmap, including feedback, proposals, and implementation plans, are documented for future reference. 

    2. Documentation is made accessible to stakeholders for transparency and accountability. 

11. Continuous Improvement: 

    1. The review and update process is iterative, with regular reviews scheduled to ensure that the architectural roadmap remains aligned with business needs and technology trends. 

    2. Lessons learned from each review cycle are used to improve the process for future updates. 

Conclusion

The review and update process outlined above ensures that the architectural roadmap of the product is regularly reviewed and updated to meet the evolving needs of the business, incorporate new technologies, and address feedback from stakeholders. This process helps to ensure that the product remains competitive, innovative, and aligned with the strategic goals of the organization.