UM : Implementation

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.

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.

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.

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 at application ? How much changes we need to do at application side ?

• 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. So, our request header should have userToken and appName.
• From above 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. For adding modifier we can do two things : 1. We can do dorequest on application facet with addModifier(cache), when we follow this approach we don't need to change anything on application side. For this approach we can enable ProjectSettings_EnforceKey, and while requesting we need this project key.  2. We can addModifier at application side itself with cacheKey. And, this cacheKey will be provided in headers/arguments with every request. In case it is not provided request will be invalid. When we follow this approach we need to change the generic mqp for application side.
• 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.

User Management Web Socket Implementation

• We need to create cache modifiers at WS for usermanagement and application. Also, we need to modify generic mqp file for application.
• We need to create 1 proxy facet for WS authentication and request routing. Proxy facet will be of type SffMsgFacet same as we created for HTTP requests. 
• Onopen of WS we will check userToken and appName. So, these parameters should be provided in URL while requesting(Dot separated). Url format : ws://localhost:9090/fid-UserManagementWS.SuperUser.UM. Here, UserManagementWS is the proxyfacetid for WS, SuperUser is userKey and UM is appName.
• We should validate userKey and appName and make the request as invalid if it is not valid. Now, we will do the authentication on the basis of userKey and generate the role. After validating userKey we need to check the appName and route our request.