[External] Using SP Entity ID in RelationalDatabase Dataconnector

Domingues, Michael D michael-domingues at uiowa.edu
Fri Mar 22 15:11:43 EDT 2019


It's your choice as to where you'd rather define the business logic. Based on Scott's response, you should be able to get at the entityID in the QueryTemplate, in which case you can still use it as a query parameter per your initial approach.

What I meant to say is that as opposed to defining MFA business logic in an external database, we found it more elegant to keep the logic defined in the IdP itself, and to just use our DB connections as raw attribute repositories.

If you do choose to shift the business logic into Shibboleth itself, I wasn't suggesting running the DB query from Nashorn (I'm not even sure what that would look like, besides some sort of hybrid scripted/RDBMS data connector). Instead, I meant that we were using the results of attributes (resolved through our standard RDBMS DataConnectors) in a script defined in mfa-authn-config.xml to make our MFA decisions.

Michael
________________________________
From: Jeff Chapin <jeff.chapin at uni.edu>
Sent: Friday, March 22, 2019 1:03 PM
To: Domingues, Michael D
Cc: Shib Users
Subject: Re: [External] Using SP Entity ID in RelationalDatabase Dataconnector

profileContext.getSubcontext("net.shibboleth.idp.profile.context.RelyingPartyContext").getRelyingPartyId(). returned as a literal (with and without the "()" -- that has not seemed to change the behavior yet).

I am looking at how to run a DB query in nashhorn now.

Jeff

On Fri, Mar 22, 2019 at 12:55 PM Jeff Chapin <jeff.chapin at uni.edu<mailto:jeff.chapin at uni.edu>> wrote:
Micheal,

I had looked at that page previously, and had thought that using a dataconnector to run the query seemed easier than writing script that can independently run a query seemed more straight forward.

I can certainly go that route, though.

On Fri, Mar 22, 2019 at 12:30 PM Domingues, Michael D <michael-domingues at uiowa.edu<mailto:michael-domingues at uiowa.edu>> wrote:
Hi Jeff,

I'll let others chime in on how (or if) you can use the entityID of a particular relying party as a parameter to a query in a DataConnector. I can tell you, however, that I'm pretty sure the entityID lives in a different context — "net.shibboleth.idp.profile.context.RelyingPartyContext" — which itself is a subcontext of the profileContext.

Given that, I think you'd use something like profileContext.getSubcontext("net.shibboleth.idp.profile.context.RelyingPartyContext").getRelyingPartyId(). Once again, I leave the wisdom of such a solution to others; it's not how we're doing it down the road.

Instead, we're resolving all the relevant attributes in a scripted context check (whether the user is eligible to use MFA, what their MFA disposition is for all relying parties, etc) and then composing the result in the script. You can find an example of a similar approach (minus the particulars of your business rule) here: https://wiki.shibboleth.net/confluence/display/IDP30/MultiFactorAuthnConfiguration#MultiFactorAuthnConfiguration-ProgrammaticallySelectingFlows

Michael

________________________________
From: users <users-bounces at shibboleth.net<mailto:users-bounces at shibboleth.net>> on behalf of Jeff Chapin <jeff.chapin at uni.edu<mailto:jeff.chapin at uni.edu>>
Sent: Friday, March 22, 2019 12:06 PM
To: Shib Users
Subject: [External] Using SP Entity ID in RelationalDatabase Dataconnector

We are trying to implement Duo, and would like to add a 'useDuo' attribute. If this is set to 'yes', that user should use Duo, and if not, not.

I have tried to set up a DataConnector with a RelationalDatabase to run the following:

select VARIABLE useDuo from dual;

when Variable is something like '$requestContext.getPrincipalName()' or 'resolutionContext.principal()' we successfully get the principal back, but I cannot seem to figure out how to get the SP Entity ID. I have tried things like:

$requestContext.getRelyingPartyId() and
$resolutionContext.attributeRecipientID()

which results in those stirngs *literally* being returned.

Ultimately, we want to query a DB and see if a given user is forced to use Duo or nor, based on business logic that is implemented and maintained in the database.


Thanks,
Jeff

--

Jeff Chapin,

Panther eSports Adviser
Assistant Systems/Applications Administrator
ITS-IS, University of Northern Iowa
Phone: 319-273-3162 Email: Jeff.Chapin at uni.edu<mailto:Jeff.Chapin at uni.edu>


--

Jeff Chapin,

Panther eSports Adviser
Assistant Systems/Applications Administrator
ITS-IS, University of Northern Iowa
Phone: 319-273-3162 Email: Jeff.Chapin at uni.edu<mailto:Jeff.Chapin at uni.edu>


--

Jeff Chapin,

Panther eSports Adviser
Assistant Systems/Applications Administrator
ITS-IS, University of Northern Iowa
Phone: 319-273-3162 Email: Jeff.Chapin at uni.edu<mailto:Jeff.Chapin at uni.edu>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20190322/260ed896/attachment.html>


More information about the users mailing list