Dependency and RDBMS QueryTemplate

Tom Poage tfpoage at ucdavis.edu
Fri Jan 19 10:33:42 EST 2018



> On Jan 19, 2018, at 5:52 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> 
>>> If not, then if I want to guarantee a value is available to the query, does one need to add that to the activation
>>> condition?
> 
> That's an interesting idea actually, I suppose you could. Normally the answer is that you fail the original dependency, backstop it with something, or use conditional logic in the query template.
> 
>> I'm not sure what your question is but the activation conditions are tested _after_ the dependencies have been run but
>> _before_ the resolver is run (or not).  I'm not sure whether it is a guaranteed (documented) semantic, but it strikes me
>> that it the the opposite would be  meaningless.
> 
> Well, to be honest, I raised that (can't recall if I filed a bug) as a possible "error" because it wasn't what I expected. I did not think dependencies of something I turned off would be run. So it definitely hasn't been what I would call a documented semantic, but if we think it's useful behavior then I guess I would rethink that.

To elaborate my particular use case:

- The query attribute used against the RDBMS connector comes from an LDAP connector. The particular LDAP attribute--or entry for that matter--may or may not exist.

- The RDBMS connector is expected to be low use. I'm trying (1) to be nice to the DB by only invoking the connector for requests from that SP, and (2) since this DB happens to be a single server (ugh), simply return nothing on connector failure (fail closed), hopefully limiting impact on the rest of the IdP service.

- As I hope the log snippet demonstrated, in the absence of the LDAP attribute, the .get(0) throws an exception. Haven't looked it in detail yet, but the exception may have interrupted evaluating the rest of the attribute context. This seems to be where the Velocity conditional comes in. Maybe something like (syntax TBD)?

<QueryTemplate>
...
WHERE #if(queryAttribute && queryAttribute.values().size() > 0)queryAttribute.get(0)#{else}-1#end
</QueryTemplate>

Or start looking at scripting this.

I haven't gone through all variations I can think of yet, but the ANDed actviation condition only seems to be satisfied (RDBMS attribute release, cf. aacli.sh) when I also release the queryAttribute in the attribute filter (which I didn't want, but may settle for). Of course, this may only reflect my lack of understanding of the sequence of operations during attribute resolution.

Thanks!
Tom.


More information about the users mailing list