9:26 p.m.
In my current saml2saml use case I need to rename an attribute (the IPD’s principalname to
surname). The quickest way for seems to be to have a second internal_attribute.yml and
initialize frontend and backend with different setting. However, there might be a more
elegant way. Is there already a microservice available that would allow me to configure
such a conversion?
Cheers, Rainer
Am 14.06.2017 um 11:12 schrieb Niels van Dijk
<niels.vandijk at surfnet.nl>:
Hi
On 14-06-17 09:19, Leif Johansson wrote:
I would prefer not do that latter, nor move the attribute mapper of satosa core into
microservices.
We should keep a strict separation of responsibilities, which are:
1) handle incoming protocol X and map to internal state (Satosa core)
2) Do some magic on internal state if needed (micro service)
3) pick up internals state and represent in protocol Y (Satosa core)
I do think therefor we need 2 mappers in the core, and in this specific case a 3th for
the magic you need:
<protocol-x> -> IDPsatosa -> mapper to internal state
Result: <internal-data>
<do your micro service magic on internal data, for example w/ a custom mapper>
Result: <modified-internal-data>
<internal-data> -> mapper from internal state ->
SPsatosa -> <protocol-y>
Both mappers from and to internal state are core to SaTosa and should I think *not* be
directly touched by any micro servcies as that will break the ability to map from and to
that data from various protocols in a generic way. They should also themselves not be
microservcies as these are core to the capabilities of SaToSa. We do not want a situation
where the protocol handling code needs to know about what internal state is going to be
represented, as that will result in the need for updating *all* protocol handlers if a new
protocol or microservice gets added.
If you have additional requirements beyond mapping from protocol to internal state, that
is up to your microservice. Microservcies should only ever touch an existing internal
state.
Cheers,
Niels
--
Niels van Dijk Technical Product Manager Trust & Security
Mob: +31 651347657 | Skype: cdr-80 | PGP Key ID: 0xDE7BB2F5
SURFnet BV | PO.Box 19035 | NL-3501 DA Utrecht | The Netherlands
www.surfnet.nl <http://www.surfnet.nl/>
www.openconext.org
<http://www.openconext.org/>_______________________________________________
Satosa-dev mailing list
Satosa-dev at lists.sunet.se
https://lists.sunet.se/listinfo/satosa-dev
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.
We could change microservices to include info about where in the
pipeline they are called - inbound, middle or outbound ... however...