8:39 p.m.
Dear all,
Am I correct in thinking that acr_mapping overrides the
AuthnContextClassRef from the user's IdP? If so, why would someone do
that? Is it for normalizing SAML AuthnContextClassRef and OIDC acr
claims?
Best wishes,
Matthew
--
"The lyf so short, the craft so longe to lerne."
10:12 p.m.
Hi Matthew,
We introduced acr_mapping in the config to allow having a default,
configurable LoA value statement for the AuthnContextClassRef in case
where there is none. (e.g. when you would have Google as an OIDC OP
connected to SaToSa). I do not think this was tested with SAML IdPs that
were capable of issuing a AuthnContextClassRef towards SaToSa themselfs
however, so if that is overwriting existing statements I cannot confirm.
Best,
Niels
On 12-02-18 21:39, Matthew X. Economou wrote:
Dear all,
Am I correct in thinking that acr_mapping overrides the
AuthnContextClassRef from the user's IdP? If so, why would someone do
that? Is it for normalizing SAML AuthnContextClassRef and OIDC acr
claims?
Best wishes,
Matthew
--
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 www.openconext.org
2282
days inactive
2287
days old
2 comments
2 participants
participants (2)
-
niels.vandijk＠surfnet.nl -
xenophon＠irtnog.org