[Satosa-dev] Proposal: callback on attribute mapping

Hi all and thanks for the responses, On 13 June 2017 at 16:24, Scott Koranda <skoranda at gmail.com> wrote: We will go forward and implement a new microservice (probably call it attribute-processor or something alike) to enable us to process attribute values before mapping them. Regarding breaking out attribute-mapper as a microservice, I had thought about it before sending the above proposal, but I feel this path leads to major changes in SATOSA's architecture. I explain my thoughts below. The attribute-mapper module is the core of SATOSA; it is the main service SATOSA offers and the point that defines the internal representation of the data and everything else is built around it. [SP(external)] <protocol-x> [IDPsatosa <> attribute-mapper:internal-data <i> microservices <i> internal-data:attribute-mapper SPsatosa] <protocol-y> [IDP(external)] By changing the role of the attribute-mapper and moving it out as a microservice what we come to is: [SP(external)] <protocol-x> [IDPsatosa <internal-data> microservices <internal-data> SPsatosa] <protocol-y> [IDP(external)] This leaves a question mark on how the internal data are generated, as attribute-mapper has been moved into microservices and is now optional. If we break out the main service that SATOSA offers then the only difference that core has compared to generalised web frameworks is its offering of an IDP and SP component. The roles of the IDPsatosa and the SPsatosa components are to *handle* requests and generate responses. The role of the microservices is to *handle* the transition from protocol-x to protocol-y. Then why would we not abstract the IDP and SP components as microservices too and generalise their usage as request and response handlers: [SP(external)] <x> [request-handlers <context> response-handlers] <protocol-y> [IDP(external)] This leads to the classic middleware architecture where defined components handle a request and then produce a response. An ordered list of handlers is set and each handler is called until no handlers are left to handle the request, then the order is reversed and each handler is called until the response is formed. This results in clear separation of the request handlers, the internal data generation and state transitions, and the response generated as a reaction to the formed state from the request handlers. Separation of concern is the primary driving factor of this architecture. This results in making the IDPsatosa and SPsatosa components as microservices -thus making them replaceable- and defines a common interface between all microservices/handlers that will be called in order. Each handler handles the request and forms a response, and thus only two methods are needed to form the interface of the handlers: handle_request(ctx, req) and handle_response(ctx, req, res) - both act on the context/ctx object. The internal-data is represented in the context object, shared and passed around the handlers, and it is the same object where state is kept during the handling of the request and the generation of the response. The whole project could then be based on a generic web framework like flask, and each microservice would be a middleware/blueprint. IMO, this is the generic architecture that any flexible and extendable network application should follow. However, SATOSA is not currently following this model, and thus will need a big refactor to fit the above architecture. Of course one could go only half way, and move only the attribute-mapper module out as a microservice, but I do not see any immediate benefits by doing this. Kind regards, -- Ivan Kanakarakis