GluuFederation/oxShibboleth

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?

yurem commented

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?

yurem commented

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

yurem commented

@ggallard Currently it should works in this way:
SP -> IDP -> IDP (oxAuth plugin) -> oxAuth -> IDP (oxAuth plugin) -> IDP (map id_token claim to IDP user principal)-> SP

It maps claims here using translator.

Here is translator code.

yurem commented

These classes have many debug output. You can enable DEBUG log level in IDP for org.gluu.idp to see how it works

yurem commented

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.

ShibOxAuthAuthServlet

AuthenticatedNameTranslator.

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.

yurem commented

@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:

  1. 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>
  1. Call gluuIdpCustomScriptManager.init()

  2. Merge your code into https://github.com/GluuFederation/shib-oxauth-authn3/tree/master/src/main/java/org/gluu/idp

  3. Call from your code gluuIdpCustomScriptManager.getIdpExternalScriptService() to get script service.

  4. Call IdpExternalScriptService.executeExternalUpdateAttributesMethod with context.

  5. Create context bean with all beans which needed in script.

yurem commented

Here is sample of contex object which we use in oxAuth.

yurem commented

Here is sample idp script.

IdpExternalScriptService.executeExternalUpdateAttributesMethod should call this script updateAttributes method with context object.

yurem commented

@malotian I've finish work on standalone custom script manager. Here is sample how to use it.

yurem commented

IdpCustomScriptManager is ready too. Her is code.

Can you call it as specified in this message?

yurem commented

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?

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 commented

@malotian yes, sure. Take your time

@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

yurem commented

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

yurem commented

Maybe something else is needed?

yurem commented

Can you merge your changes to branches version_4.2.1 to allow simply install idp.war without manual changes?

yurem commented

image