Apply attribute filtering code to inbound attributes

Description

Need to flesh out use of the filter engine applied to inbound IdPAttribute data.

Includes review and addition of any necessary matchers or rules for issuer side, possible adjustment of existing action beans or new ones to populate issuer metadata.

The only special consideration I recall from the SP is that I allowed for wildcard rules that avoided the need to identify every inbound attribute. I'm not sure that same consideration applies to the IdP for proxying but it might, since the only way to even pass the data on through to an SP later would be through a DataConnector of some kind.

Environment

None

Activity

Show:

Scott Cantor December 17, 2019 at 3:23 PM

This is wired into the SAML proxy flow also, and has worked more or less fine.

The original motivation in the SP behind the wildcard notion was to make it possible to define a new inbound attribute mapping in one place (the extractor file).

The IdP isn't exactly a different case, but for the time being I'd rather not introduce a new notion unless it proves necessary, and our intent for the mapping rules in the IdP is to leverage pre-built transcoder rules that people can share anyway.

Scott Cantor May 31, 2019 at 7:51 PM

Added Inbound and Outbound rule types and a tracker for it in the filter context.

Rod Widdowson May 31, 2019 at 4:09 PM

This is all completed. Document review would be welcomed

Rod Widdowson May 31, 2019 at 3:43 PM

Parsers written documentation pending

Rod Widdowson May 31, 2019 at 1:59 PM

Written the matchers plus associated tests. Next up is the Spring bit

Done
Pinned fields
Click on the next to a field label to start pinning.

Details

Assignee

Reporter

Components

Fix versions

Created May 23, 2019 at 12:50 PM
Updated March 11, 2020 at 2:10 PM
Resolved December 17, 2019 at 3:24 PM