We are a software house specialized in certain niches of retail industry, we use Microsoft tools and systems.
For a new system we are building, we need to add a new authentication and authorization component.
This new system is highly distributed among sites, and machines; it also needs to apply to several deployment topologies, from multitenant cloud SaaS, to all-in-one on a branch server. Most of the instances will not have all the components and services of the solution, that's the reason to ask for a separate auth Service.
The goal of the project is to outsource the design and development of an Authorization and Authentication Solution (the Service) with the following items,
Deliverables: Detailed technical specification artifacts (*)
b) Development (Optional, would be a separate Freelancer project)
Deliverables: Source code
Candidates may submit offers for Design or Design and Development
The Service must comply with the following business requirements,
1) 100% based on standards. It must implement OAuth 2.0.
2) Based on #1, its interface -both in data and endpoints, must be compatible with third parties' services also based on OAuth. (Reason: Eventually this component could be replaced or integrated by a third party provider for the SaaS instance or a few large customers) This specific requirement could be fulfilled by implementing it, or just leaving this integration considered and well documented in the project.
3) The service will be .net core 2.0 compliant, based on stable components or libraries (mainstream Nuget packages) if needed. Preferably, Microsoft-sourced/backed packages. In on-premise scenarios, the service will run as a Windows service.
4) At the contractor's discretion, the Service will be also responsible for the administration of the Users, Roles and Permissions of the Solution.
5) The Service must also expose its own telemetry and health check data, and react to a short list of actions thru an IoT connection, using Azure IoT Hub SDK. Actions can be proposed by the contractor, at least service stop/restart and receive/apply Service's local JSON configuration from the Hub.
6) From a functional standpoint, the Service must provide the endpoint and the functionality for:
a) Support end-user logins from UIs implemented on different components of the Solution. Each component/product is responsible to implement it's own UI interaction.
b) By means of trusting on the Service, the trusting component will get the full list of claims of the user, and any other data to internally resolve user's permissions within the component.
c) Any other given component/service/application of the Solution will be able to authenticate itself on behalf of a specific user or application-to-application.
d) Third-party application will be validate its credentials to integrate to the Solution using a well-known application pattern, possibly using an application token given at registration time (registration process is beyond the scope of the Service)
(*) Design artifacts
Expected (contractor may suggests improvements or changes according to her/his experience)
- Overall architecture (Package Diagram, Components diagrams, Document with Abstract, Design considerations, Limits, Risks)
- Class diagram
- Sequence diagram (at least relevant or complex interactions)
- DTO and Storage schemas
- Recommended/Required packages or components considered on the design
- Integration guide for the client applications/modules
[Documentation should be explicit about the impacts, limits, and any other consideration applicable in order to replace -or integrate- the Service with a third party authentication and authorization service]