tech note
Checking of Management Portal credentials should happen through API or direct in the existing application.
If the account was not found, ? ( where to check this)
then the browser should POST the same username/password over to the Management Portal via a JS POST. ( Which Api )
This page will likely be a modified version of the existing page to be easier to integrate to the login html application,
and ideally should accept JSON payload posts and respond with JSON.
If we can use the exact same login page control and simply check the payload before doing the normal load to know what “mode” it’s being requested to operate in.
So if the content type is application/json, then we know to check the body as JSON to get the username and password to validate against DNN.
The existing DNN/Management Portal authentication process will be used, if successful then then user will be authenticated, and the back end code will migrate the users by posting a registration request to the API, which will add the new user account and respond back with a JWT
Note: If authentication fails at the management portal during this step, we’ll need to be able to pass back the login failure messages back to the new HTML Login application. See above for a possible strategy of modifying the existing page to operate as a JSON endpoint.
The JWT will be sent back into the browser and stored in session storage.
The browser will continue onto the DNN site as usual.
Are we going to use the same encryption format in the postgres database that is being used in the Management Portal?
In every case we should be using the standard .NET Core 6/Standard Identity setup
. So for the encryption/password hash we will need to take the clear text password that was passed and during registration the Identity library will take care of the password encryption/hashing for us.
Should we block the user from accessing after 3 wrong attempts.
We should look into how to configure that to work with .NET Identity if it’s possible to have that library handle it for us. So if the user is “already migrated” then the ASP.NET Identity system will handle that for us, but if they are not yet migrated then whatever exists in the Management Portal will have to be relied upon.
This option simply needs to be researched but not yet implemented.
While migrating the user information from the management portal . We need to migrate their Roles and list of Schools they can access. How are we planning to do that as the Role Id and school Id may differ ? (are we going to do directly or through nightly job)
We need to figure out how we will migrate that information as well. The schools will be stored in the Business API and can be accessed by GUID (or other query params). We would likely then need to add a table to the Users API tables that would be a user to schools relationship table.
During migration then, the process will pull in the list of schools and insert them into a Users API table for that user
When we build the drop down in the new login system to allow them to select a school, we would need to post to the Business API the guids of the schools that are joined to the user, the response then we use for a drop down to allow them to select the school.
Example POST of school_uuids
POST: /api/schools/query
{
“id”: [
“8765edc6-b480-41af-9c96-c6a0ffd8e1ee”,
“98a67538-6bc8-4278-834c-5a4c794c475a”,
“5b58f804-17f0-4ec4-812e-00a00bd038f3”
]
}The alternative is that we have the Users to Schools table in the Business API. In that case we simply need to get the list of schools by user - however that probably inverts the responsibilities of the service (where now the Business API is responsible for storing user authorization data).
As for the modification of a user we have two options
Add support for API calls on the User edit pages in the DNN module. If any user details are changed, then post those changes over to the Users API to update (password, roles, personal information)
Develop a basic User Management tool in the Pay Management Web App. If a user is migrated, then the new tool would need to be used. We would be able iframe the new tool in the same way we do other Pay Services tools.
---------------------------
@page
Comments
Post a Comment