-
Type:
New Feature
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 4.0.0
-
Component/s: Attribute Mapper, Attribute Resolver
-
Labels:None
Time to take a stab at revamping this into a separate service with a new "separate" configuration for mapping between attribute representations.
I don't think we need to necessarily be compatible with the current APIs in either direction, as this hasn't been a major area of third party development, aside from the OIDC equivalents that we can change as needed.
I would like to start with a strawman proposal for doing this with native Spring, probably allowing for compatibility with the resolver as a "legacy" option along the lines of how the RelyingParty support was done, but it may be more practical to come up with a new syntax.
I'm inclined to model more of this on my SP's AttributeDecoder model just because I understand it a lot better than the AttributeMapper code from V3, but I'll see how it goes.
I'm attracted to the idea that we could have more of a symmetric design with each plugin being required to support both directions, i.e. a SAML 2 encoder that supports String values has to also support decoding all SAML 2 constructs back into String IdPAttributeValue objects and so on.
1.
|
Create OIDC transcoders |
|
Closed | Scott Cantor | ||||||||
2.
|
Create SAML transcoding rules |
|
Closed | Rod Widdowson |
|
|||||||
3.
|
Add I18N to transcoding rules |
|
Closed | Rod Widdowson | ||||||||
4.
|
Create CAS transcoders |
|
Closed | Scott Cantor |
|