8:53 p.m.
We have an Incommon Application that is sending a list of three (3) requested attributes.
Even though KeyCloak is passing all of the attributes we have configured, once it is
filtered out by Satosa it is only passing on the attributes that the actual SP from
InCommon requested. Is there a way to override this?
9:33 p.m.
Hello Bryan,
the easiest way to bypass this filter is to connect the entity without
RequestedAttribute elements in the metadata. If the filter does not
have a set of attributes to filter, it will not filter any attribute.
This default behaviour adheres to the data minimization principle. If
an entity requests specific attributes, only those that are required
are released.
I hope this helps.
Kind regards,
On Tue, Mar 19, 2024 at 10:53 PM <bryan.l(a)fischeridentity.com> wrote:
We have an Incommon Application that is sending a list of three (3) requested attributes.
Even though KeyCloak is passing all of the attributes we have configured, once it is
filtered out by Satosa it is only passing on the attributes that the actual SP from
InCommon requested. Is there a way to override this?
_______________________________________________
satosa-users mailing list -- satosa-users(a)lists.sunet.se
To unsubscribe send an email to satosa-users-leave(a)lists.sunet.se
--
Ivan c00kiemon5ter Kanakarakis >:3
11:27 p.m.
Thanks Ivan! We have been working with our Client on this and have explained to them about
this and asked that they go back to the application (Service Provider) to make the changes
or completely remove those if they want the IdP to decide what it releases. It looks like
the Client was using Shibboleth IdP and that would just release everything regardless of
just what the application was asking for.
60
days inactive
60
days old
2 comments
2 participants
participants (2)
-
bryan.l＠fischeridentity.com -
Ivan Kanakarakis