Feature #377

session verification service

Added by Madars Vitolins 4 months ago. Updated 3 months ago.

Status:NewStart date:01/25/2019
Priority:NormalDue date:
Assignee:-% Done:


Target version:-


incoming requests could be forwarded first for "forward server" or to "verification server" the forwarder can be used for UBF only. the verification server is request/reply for other buffers. So that we can validate sessions.


#1 Updated by Madars Vitolins 4 months ago

We could add session handling via caches (hits + expiry or new strategy of expiry update on access).

And use service access filter lists, something like:

read=Read user data
write=Add new user
update=Update user
delete=Delete user
list=List users

# Accept any from sysadmin
accept 0 = ACL_SYSADMIN
# Reject if not having user name (thus no session)
reject 1 = !ACL_USERNAME
# verify that user belongs to insitution
reject 1 = !chk_inst_username()
accept 2 = ACL_READ && API_FNCODE=='read'
accept 3 = ACL_WRITE && API_FNCODE=='write'
accept 4 = ACL_UPDATE && API_FNCODE=='update'
accept 5 = ACL_DELETE && API_FNCODE=='delete'
accept 6 = ACL_LIST && API_FNCODE=='list'
# if we got so far, then accept
reject 99 = 1==1

read=Login into system

# accept if have user name & password
# reject if got so far...
reject 99 = 1

So we need API for:

restincl target service, loginsvc -> @GETSESSION, if missing, forward to @LOGIN (which forwards to @GETSESSION again for storing by session key...) -> @ACCESSRULES -> target_service

#2 Updated by Madars Vitolins 4 months ago

restincl target service, loginsvc -> @GETSESSION, if missing, forward to @LOGIN (which forwards to @GETSESSION again for storing by session key...) -> @GETACL -> @ACCESSRULES -> target_service

LOGINSVC = <User login service>

ACLSVC = <User ACL Service>

Only needs to think how to limit the services which user can list in roles screen. Maybe we need some kind of system role and then filter service which to return to user and shall not return?

#3 Updated by Madars Vitolins 3 months ago

The project could fallback to following parts:

1. Generic access permissions checking service, for example "experms" to which "SRVCNM" is passed (target service). if experms config says forward, then if rules passed message is forwarded to SRVCNM, if no forward is set, then tpreturn tpsuccess is returned. Rules section can be configured too i.e. to use "[@RULES/SVCNM]" or "[@RULES2/SVCNM]", etc... Also default logic shall be defined, if no section found, then reject or accept the call. If call is not accepted, then EX_IF_ECODE shall be set to 8 -> and set corresponding message in EX_IF_EMSG e.g. "reject 99".

The server for each section shall add entry in new hash list which would hold the list of compiled rules linked lists. On new request, we lookup the hash, if entry is found, then go over the linked lists of permissions and evaluate the buffer. If hash entry is not found, then lookup the config section, if found, compile each rule, add to linked list, add linked list to hash which is build by section/subsection name.

2. Update restincl to have two 4x new params for each service (or default):

- "in"
- "inoptsvcs" comma separated list of vital service to be executed on buffer



for example:

/view/httpe/fail={"svc":"VIEWFAIL", "conv":"json2view", "errors":"http", "async":false, 
        "view_notnull":true, "in_fltr_mand":"VIEW2UBF", "in_fltr_opt":"AUDITREQ,AUDIT2", "out_fltr_mand":"UBF2VIEW", "out_fltr_opt":"AUDITRSP"}

Thus in this case the request will be chained via firstly via "in_fltr_mand" then via "in_fltr_opt" services.
The buffer format can be switched during the processing i.e. we might get json, and or view and "VIEW2UBF" will convert to UBF.

Also we might need a new buffer format, like "ubfemb", so that the raw message is embedded in the "EX_NETDATA", also for this
"ubfemb" we could load all header in the buffer, before forwarding filter chains. In case if chaining is enabled, then "SRVCNM" shall be set for in/out chains and afterwards deleted. for UBFEMB json2ubf buffers

At the respnose phase the "out_fltr_mand" could prepare in ubf buffer "EX_NETDATA" for sending response to network.

In case "in_fltr_mand" fails, then error shall be sent to network, if response code is 11 and buffer has EX_IF_EMSG/ECODE then this shall be loaded
in the response message. if fields are not available, then generic error code shall be provided to network.

With these changes we solve following issues:

- Can have a message convert servers
- Can chain a service access permission checkers

on response

- we can conver message back to network format via response converter

Also available in: Atom PDF