This is not necessarily a bug, maybe it's just configuration incompetence on my end. I don't really know where to debug (more), so asking here for inspiration.
Running 5.0, I have defined a custom scope:
'magicmushroom' => [
'description' => '...',
'claim_name_prefix' => '',
'are_multiple_claim_values_allowed' => false,
'claims' => [ 'magicmushroom' ]
],
with the SAML-to-OIDC attribute definition
'magicmushroom' => [
'urn:restena:magicmushroom',
],
The server seems to have accepted that definition, looking at its .well-known metadata:
"scopes_supported":["openid","offline_access","profile","email","address","phone","groups","magicmushroom"]
I now have a client that requests "magicmushroom" but a dump of the id_token on the receiving end does not contain this scope+claim.
The SAML attribute "urn:restena:magicmushroom" exists SAML-side, it comes in via an sqlAttribs authprocfilter which is defined specifically in the OIDC module's config:
ModuleConfig::OPTION_AUTH_PROCESSING_FILTERS => [
4 => [
'class' => 'sqlattribs:AttributeFromSQL',
...
],
Within SAML auths, the attribute is passed to SPs as per the attributes definition of those SPs.
So, I fail to see why this attribute is not released as a custom scope in the OIDC context. My best bet could be that maybe attributes that are defined with an authprocfilter are "too late" and not being considered by the module?
This is not necessarily a bug, maybe it's just configuration incompetence on my end. I don't really know where to debug (more), so asking here for inspiration.
Running 5.0, I have defined a custom scope:
with the SAML-to-OIDC attribute definition
The server seems to have accepted that definition, looking at its .well-known metadata:
"scopes_supported":["openid","offline_access","profile","email","address","phone","groups","magicmushroom"]I now have a client that requests "magicmushroom" but a dump of the id_token on the receiving end does not contain this scope+claim.
The SAML attribute "urn:restena:magicmushroom" exists SAML-side, it comes in via an sqlAttribs authprocfilter which is defined specifically in the OIDC module's config:
Within SAML auths, the attribute is passed to SPs as per the attributes definition of those SPs.
So, I fail to see why this attribute is not released as a custom scope in the OIDC context. My best bet could be that maybe attributes that are defined with an authprocfilter are "too late" and not being considered by the module?