Dynamic SAML Attribute Interception Script
Closed this issue · 31 comments
We don't like to use shib dynamic attribute scripts, because they are hard to maintain. Ideally, this kind of script would be a standard interception script. Is there any way to connect Shibboleth to call an interception script defined in oxTrust?
sample/example to understand enhancement
let say user’s age is stored as number. and we wanted to release like Toddler/Young/Adult/Old etc etc (instead of number)
Idea is to be able to write in python like other scripts (in friendly manner)
where user gets hashmap of attributes in a function call, user can edit map in python and modified will be released by shibb
do we have any updates on this guys? do you need any additional information or something that we can help to move forward this?
The flow it’s not clear. Right now IDP gets user attributes from OpenID id_token and translate them to allow build Saml response.
If we still need to consume id_token in IDP why we can’t send right claims from oxAuth?
Based on answer on first question we need to find proper place to call this new script.
The goal here is to enable dynamic claims... i.e. claims that are not stored in the database.
Also, as you know, the id_token may or may not have user claims (i.e. only if legacy_id_token is true). If the claims are not present, does Shibboleth use the Userinfo token?
I see. These points explains target and also answer on question where to call this script. I'm going to reassign this issue to myself
Based on our observations, IDP is getting the attributes directly from LDAP/CB, not from the id_token or userinfo endpoint.
https://github.com/GluuFederation/oxTrust/blob/master/configuration/src/main/resources/META-INF/shibboleth3/idp/attribute-resolver.xml.vm
Am I missing something?
If it were getting those attributes from the returning id_token, it would be much easier, since we already have (OIDC) dynamic claims solved.
@yurem I have alreday reserached about how to update attributes, after authn. Please advise me how I can integrate it with Jython
I already have sample code working (purely on shibb side as of now), I need your guidance on how to integrate it with Interception scripts
These classes have many debug output. You can enable DEBUG log level in IDP for org.gluu.idp
to see how it works
In any case we will add new script to allow map claims to IDP client credentials externally. It should be called from translator class
@yurem are you saying that we will introduce interception script in translation only ? But I guess shibboleth also make connections to LDAP/User Directories for fetching additional attributes.
I don't think so code referred here take into consideration about the configured Attributes for SP.
And If I understood correctly idea of this issue was to manipulate the attribute name and values, just before releasing those in assertion.
If above is true, I have already looked at the way to do this - https://github.com/malotian/malotian-shibboleth-release-attributes-post-processor
@nynymike please comment on my understanding
I think you're on the right track. Can the post-processor call an interception script? What if different SP's need to call different scripts? How would we signal from the SP config in oxTrust?
I think you're on the right track.
Good to Know
Can the post-processor call an interception script?
Yes post processor can call any java code, i have done a P.o.C. to call a java class/function.
now from Java using jython we can route it to python scripts
What if different SP's need to call different scripts? How would we signal from the SP config in oxTrust?
I guess that can be handled some how by passing context (may be script name) to main script - single entry point configured at shibboleth,
and inside main script, we will receive context (another script name) etc etc... I would say these are doable on eot another way.
I guess main point is connecting jython, python interface in java code.
read P.o.C Code for ReleaseAttributesPostProcessor here just to modify I have removed - givenName
and added/updated - surname before embedding into assertion.
Now what is left is, to pass on attribute map to python script from this java code.
python code will do modifications to attributes
then java code will receive modified attributes (from python), and finally those will be used to for assertion
@yurem here I need your help - to pass on attribute map to python script from this java code
@yurem could please read above, and need your quick guidance to integrate with jython, shibb side is more of ready. needs to be integrated to jython and frontend.
@malotian I'm planning to finish tomorrow custom script update to allow reuse it in IDP.
We can split our work to work on it in parallel.
We can do next:
- Create Idp custom script manager using xml like this:
<bean id="gluuIdpCustomScriptManager"
class="org.gluu.idp.script.service.IdpCustomScriptManager">
<constructor-arg name="configurationFactory" value="#{idpConfigurationFactory.instance()}" />
</bean>
-
Call
gluuIdpCustomScriptManager.init()
-
Merge your code into
https://github.com/GluuFederation/shib-oxauth-authn3/tree/master/src/main/java/org/gluu/idp
-
Call from your code
gluuIdpCustomScriptManager.getIdpExternalScriptService()
to get script service. -
Call
IdpExternalScriptService.executeExternalUpdateAttributesMethod
withcontext
. -
Create context bean with all beans which needed in script.
Here is sample idp script.
IdpExternalScriptService.executeExternalUpdateAttributesMethod
should call this script updateAttributes
method with context object.
I've finished work on updates. All components works well. There is only one issue. IDP not call our bean. @malotian I've added call from place which you mentioned. It's path 61. Additionally I've added path 62 when I tried to find why IDP not call it. Did you shared all xml spring changes?
Great @yurem, I will look at this soon. should be working soon
@yurem please get “jython-ntegration” branch for oxShibboleth & shib-oxauth-authn3, and
then add p:postAuthenticationFlows="#{{'attribute-release', 'gluu-release-attributes-post-processor'}}"
to SAML.SSO
bean inside relying-party.xml
e.g.
<bean parent="SAML2.SSO" p:postAuthenticationFlows="#{{'gluu-release-attributes-post-processor'}}" />
this update to relying-party.xml
we will do via gui (velocity templates), but lets test in principle first
I've build idp.war from jython-integration
an applied this update:
--- relying-party.xml.orig 2020-08-28 11:44:45.973887293 -0700
+++ relying-party.xml 2020-08-28 11:44:34.492052731 -0700
@@ -49,6 +49,7 @@
p:signResponsesPredicate-ref="SignNoIntegrity"
p:signAssertions="false"
p:encryptNameIDs="false"
+ p:postAuthenticationFlows="#{{'attribute-release', 'gluu-release-attributes-post-processor'}}"
p:encryptAssertionsPredicate-ref="EncryptNoConfidentiality" />
<bean parent="SAML2.ECP"
But it still not call script method
Maybe something else is needed?
Can you merge your changes to branches version_4.2.1 to allow simply install idp.war without manual changes?