Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Objective

  1. User management will be standalone application that should be deployed in parallel with other application.
  2. User management data should not be affected if we redeploy or delete other application.
  3. Option to enable/disable user management.
  4. We have to deal with two types of requests, UM and application based.

Login, Logout, Change/Reset Password

  1. Login : From User management UI user will login, request will go to UM authentication facet for validation.
  2. Logout : Request goes to authentication facet and will delete the session and facet data.
  3. Reset Password : Request goes on UserManagement FacetIDName endpoint with user name in request.
  4. Change Password : Request goes on UserManagement FacetIDName endpoint with user name, old password and new password in request. Request will be rejected if userToken is not valid. Before changing the password old password and new password will be validated.

Gliffy
imageAttachmentIdatt1091436694
baseUrlhttps://atomiton.atlassian.net/wiki
macroId97989a46-9f64-4b6d-8ccd-6fb44a834773
nameUM-LoginFlow
diagramAttachmentIdatt1090945194
containerId1103101956
timestamp1550483034277


Roles, Capability, Mapping and Grant permission

  1. Create Role, capabilities, mappings, permission etc : These all requests should goes to UM Facet endpoint. On request userToken will be verified and will get rejected if it is not valid. Cache modifiers will also be applicable while doing operations on role, capability, mapping etc. Users mapped with roles having access of these data models can only be able to perform these action.
  2. Cache modifiers : Cache modifier should be created on both FacetIDName and WSFacetIdName for every role. We also need to create cache modifier on application for those models which are associated with that application.


Gliffy
imageAttachmentIdatt1090715778
baseUrlhttps://atomiton.atlassian.net/wiki
macroIda777740d-0971-4303-8b77-7b3b2b9eb6bc
nameUM-MappingFlow
diagramAttachmentIdatt1103134747
containerId1103101956
timestamp1550483701011


Handling of all HTTP request :
  1. There will be two modes of requests based on the application i.e UM and application based. 
  2. UM requests should be handled at UM facets after modification and application based requests will be handled at application facets after fetching application details from applicationDetails data model.


Gliffy
imageAttachmentIdatt1103101972
baseUrlhttps://atomiton.atlassian.net/wiki
macroIdf4ce0804-9210-4912-86b1-0a09d62a098d
nameUM-RequestFlow
diagramAttachmentIdatt1091436712
containerId1103101956
timestamp1550484239660


How cache modifier will be created on UM and application ?

  • User will create role and capabilities. Those user who have the read-write access of these models could only be able to create these.
  • After creating role and capabilities, user will do the mappings of role-capability and capability-model association with permissions[ReadWrite, ReadOnly, Hidden].
  • RoleBasedModelModifier will be called after mappings, this will create cache modifier at FacetIDName and WSFacetIDName.
  • We need to filter models before creating cache modifier as some of the models belongs to application also. Use show entity on UM to find out.
  • Filter those models which belongs to applications, create cache modifier at UM ( do request on Facetid and WSFacetID).
  • Now, do request on application facet and find out the models that belongs to that application and make a list of that.
  • Do request on FacetID and WSFacetId to create model modifier on that application


How request could be handled ?

  • As we have two applications and our authentication is happening at UM side. But, requests may belongs to UM or application. Application models/macros would not be available from UM. So, we need to redirect those request to application facets. So for every request we need to filter whether request belongs to UM or application.
  • We need to create 1 data model at UM to save application details(sysid, appName, appFacetIdName, appWSFacetIdName, appServer, appPort).
  • We need to modify our request format and have to add appName in request header.
  • From here we can filter our request whether it belongs to app/UM.
  • UM requests will be handled easily as we have cache modifier created right there. We need to add modifier with every request for that role. For that we need to capture userToken from header and find out role associated with it. And, we need to add modifier for that role.
  • Now, for application requests. We need to add modifier at application side and do request on application facet with modified request. Cache modifier will be applied as we have already created cache modifier before while creating role.
  • Issue while applying cache modifier : one issue that will come while applying cache modifier is while creating cache modifier it expects 1 hidden attribute. And, we have handled this in our previous approach by creating 1 dummy hidden model at UM side. But in our new case we are creating cache modifier at application also, so we need to add 1 hidden model there also.


Jira Tasks 
S.NoTask IdDescriptionStatus
1TQLPROD-2574Jira Epic : with all the details of UM works to do.Work in Progress
2TQLPROD-2580Create Data Model for ApplicationDetailsPartially Done, Created model, I need to write an macro for validating the application end point.
3TQLPROD-2581Code for creating cache modifier at application end pointsDone for HTTP and Tested that also.
4TQLPROD-2582Restrict application for outside use and add code to UM to access after validation onlyDone, restricted the application for the outside use by enforcing key, added a field in appdetails in data model for saving application key.
5TQLPROD-2583Macro for listing all models of UM and applicatonNot started
6TQLPROD-2584Redirect requests to ApplicationCoding done, need to test this properly for invalid inputs also.
7TQLPROD-2585Create 1 dummy hidden model at applicationNot started
8TQLPROD-2586Create Cache modifier on application after every redeployNot started