shibboleth.InterceptFlow - share DB Connection Pooling with Shibboleth via 'global.xml'

Joshua Brodie josbrodie at
Tue Sep 11 00:39:19 EDT 2018

Hey I was looking for similar. With difference in that allow user to update
the DB with new reset questions/answers if they do not match a criteria
(weaker older questions from 20 years ago).I only occasionally work with
Shibboleth and am a bit lost.

I have been looking at examples
Halfway through the list, so far none appear to have DB  calls. Please post
if you find pathway.

On Mon, 10 Sep 2018 at 18:05, Lionel Samuel <lionel.samuel01 at>

> Darn....unfortunately we have to perform both read/write... basically will
> allow users option to bypass password reset up to X times on expiry (by
> setting a counter in DB). And will also display pages where user can
> interact with counter -- be redirected app where can reset password.
> I have it working -- but with a DB connection in XML file local to the
> JAR. Trying for last few days -- I can't figure out how to get the global
> context and piggyback the Db connection/pooling in 'global.xml'  --- could
> anyone point me perhaps to an example?
> public ResetPasswordCounter() {
>             super();
>"ResetPasswordCounter.constructor()", "loading
> db-connection.xml ", null);
>             this.context = new
> ClassPathXmlApplicationContext("db-connection.xml");
>             this.ResetPasswordCounterModel =
> (ResetPasswordCounterJDBCTemplate)
> context.getBean("resetPasswordCounterJDBCTemplate");
>         }
> On Fri, Sep 7, 2018 at 11:38 AM Cantor, Scott <cantor.2 at> wrote:
>> On 9/7/18, 2:06 PM, "users on behalf of Lionel Samuel" <
>> users-bounces at on behalf of lionel.samuel01 at>
>> wrote:
>> > We are building a shibboleth.InterceptFlow --- is it possible for the
>> plugin (which will be checking for password expiry
>> > against a DB) -- to share DB connection pooling from 'global.xml'? I
>> wasn't sure how to call out to share the pooling..
>> Well, I wouldn't do it that way (I would use the attribute resolver to
>> just get the data for you and then use the existing interceptor to check
>> it) but that aside, you don't "call out" to anything, you inject the
>> desired bean into your object to use it (a settable property of type
>> DataSource in this case). And yes, anything named in the global context is
>> visible for injection.
>> But you don't need to do all that, it's much easier to let the resolver
>> handle it, you're just duplicating effort.
>> -- Scott
>> --
>> For Consortium Member technical support, see
>> To unsubscribe from this list send an email to
>> users-unsubscribe at
> --
> For Consortium Member technical support, see
> To unsubscribe from this list send an email to
> users-unsubscribe at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list