using idp.oauth2.refreshToken.activation
Bergmann, Clemens
clemens.bergmann at tu-darmstadt.de
Mon May 18 13:52:39 UTC 2026
Hi Scott,
thanks for the confirmation.
I was able to set the property to the bean with the bean defined as show bellow.
I would suggest adding an option to the OAUTH2.Token profile configuration bean [1] that would override idp.oauth2.refreshToken.activation. We are
using OAUTH2.Token.MDDriven and this would allow us to simply set this option to 'shibboleth.Conditions.TRUE' for this single RP to override it. This
would simplify our configuration and improve maintainability.
If you are interested I can look into this route and send a diff with a first draft of an implementation.
[1] https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/2931327005/OPToken
Kind Regards
Clemens (Bergmann)
<!--literal copy of NotClientCredentialsGrantCondition because of dependencies -->
<bean id="TuDaNotClientCredentialsGrantCondition" parent="shibboleth.Conditions.NOT">
<constructor-arg>
<bean class="net.shibboleth.idp.plugin.oidc.op.messaging.context.logic.RequestedGrantTypesCondition"
p:grantTypes="#{T(com.nimbusds.oauth2.sdk.GrantType).CLIENT_CREDENTIALS}" />
</constructor-arg>
</bean>
<!--literal copy of BuildOIDCTokensCondition because of dependencies -->
<bean id="TuDaBuildOIDCTokensCondition" class="net.shibboleth.idp.plugin.oidc.op.profile.logic.IssueIDTokenCondition" />
<!-- modified copy of RefreshTokenActivationCondition -->
<bean id="TuDaRefreshTokenActivationCondition" parent="shibboleth.Conditions.AND">
<constructor-arg>
<list>
<bean class="net.shibboleth.oidc.profile.config.logic.RefreshTokensEnabledPredicate" />
<ref bean="TuDaNotClientCredentialsGrantCondition" />
<bean parent="shibboleth.Conditions.OR">
<constructor-arg>
<list>
<bean parent="shibboleth.Conditions.NOT">
<constructor-arg>
<ref bean="TuDaBuildOIDCTokensCondition" />
</constructor-arg>
</bean>
<bean parent="shibboleth.Conditions.AND">
<constructor-arg>
<list>
<ref bean="TuDaBuildOIDCTokensCondition" />
<bean class="net.shibboleth.idp.plugin.oidc.op.profile.logic.OfflineAccessScopeCondition" />
</list>
</constructor-arg>
</bean>
</list>
</constructor-arg>
</bean>
<!-- Begin TUDa Specific code -->
<bean parent="shibboleth.Conditions.EntityDescriptor">
<constructor-arg name="pred">
<bean parent="shibboleth.Conditions.MappedEntityAttributes">
<constructor-arg>
<list>
<bean parent="shibboleth.TagCandidate"
c:name="https://idp.hrz.tu-darmstadt.de/attributes/sendRefreshToken"
p:values="true" />
</list>
</constructor-arg>
</bean>
</constructor-arg>
</bean>
<!-- End TUDa Specific code -->
</list>
</constructor-arg>
</bean>
--
Clemens Bergmann
[er/ihm; he/him]
Team Linux/Team IDM
Technische Universität Darmstadt
Hochschulrechenzentrum, Alexanderstraße 2, 64283 Darmstadt
Tel. +49 6151 16 71184
Matrix: @cb50tory:matrix.tu-darmstadt.de
</bean>
http://www.hrz.tu-darmstadt.de
Am Freitag, dem 15.05.2026 um 12:52 -0400 schrieb Scott Cantor via users:
> Assuming that the use of the condition is actually inside the flow and not inside e.g., the relying party service...
>
> If there's no existing import of a configuration resource that ends up inside the flow, I'd probably just look at duplicating the actual definition
> of that referenced bean to recreate it, but that only works supportably if the definition doesn't use any impl classes.
>
> If it's impl now, it probably needs to be made API for exactly that sort of case.
>
> Of course, actually duplicating the functional behavior of the default condition is also a stopgap.
>
> -- Scott
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6229 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/users/attachments/20260518/655dd52d/attachment.p7s>
More information about the users
mailing list