Developing login plugin

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Developing login plugin

Joseph Fischetti

Good morning,

I’m working on modifying the Shibboleth-Totp plugin that was developed and is available on github so that it actually works with the MFA flow that’s available to the IDP now.  The way the plugin was originally developed, it runs its own password flow, and it needs to be referenced directly in idp.properties.  It was also written to use its own seed fetcher, which seems counter intuitive when the IdP has the attribute resolver available to it so I don’t see a point in reinventing the wheel creating new directory connections etc.

 

My question revolves around calling the attribute resolver, I’ve included some code below.  I currently have it working, but I want to make sure it’s working correctly based on the way the IdP is plumbed.  Many of the examples available use script provided via XML.  There’s not much out there for actually programming plugins.

 

High level:  The flow is called and it looks at the c14n principal name from the profileContext that’s passed to it.  It then hands off to an ‘AttributeSourcedSeedFetcher’ (code provided), which loads the username into an AttributeResolutionContext.

The AttributeResolutionContext needs the AttributeResolverService when resolveAtributes is called.  I’ve passed that in via a bean.  I then get the attribute, and remove the subcontext for the AttributeResolverContext.

 

Thanks all

Joe Fischetti

 

Note I’ve stripped out the unnecessary content below.

Username is passed in upstream via the profileRequestContext.  attrRes and seedAttribute are passed in via the bean below.

 

------------------------------------------

 

AttributeResolutionContext resCtx = (AttributeResolutionContext)profileRequestContext.getSubcontext(AttributeResolutionContext.class, true);

resCtx.setPrincipal(username);

 

                //Define the arraylist of attribute values to pass into the resolver

ArrayList<String> seedAttributeList = new ArrayList<String>();

seedAttributeList.add(seedAttribute);

 

                //Add the attribute names to the resolver

resCtx.setRequestedIdPAttributeNames(seedAttributeList);

 

                //Resolve the attributes

resCtx.resolveAttributes(attrRes);

 

                //Get the results

Map<String,IdPAttribute> attributeResults = resCtx.getResolvedIdPAttributes();

 

                //Get just the attribute we care about (This can be condensed into the line above)

IdPAttribute attribute = attributeResults.get(seedAttribute);

 

                //Parse the values

if (attribute != null) {

//Run through the returned values and act

}

 

else{

//Handle it

}

               

                //Remove the subcontext for the resolver (is this the ‘unpinning’?)

profileRequestContext.removeSubcontext(resCtx);

 

 

 

---------------------------------------

 

<!-- For AttributeSourcedSeedFetcher

Pass in the attrRes, and the seed attribute from the config file-->

<bean id="shibboleth.totp.seedfetcher" class="net.kvak.shibboleth.totpauth.authn.impl.seed.AttributeSourcedSeedFetcher"

p:attrRes-ref="shibboleth.AttributeResolverService">

 

<constructor-arg ref="shibboleth.authn.seedAttribute" />

</bean>

 

 

Joe Fischetti

Linux System Administrator

Marist College

 

E-mail: [hidden email]

 


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Developing login plugin

Cantor, Scott E.
On 11/19/19, 9:11 AM, "dev on behalf of Joseph Fischetti" <[hidden email] on behalf of [hidden email]> wrote:

> My question revolves around calling the attribute resolver, I’ve included some code below.  I currently have it
> working, but I want to make sure it’s working correctly based on the way the IdP is plumbed.

Mostly. I would stuff the contexts under the AuthenticationContext to keep them safely isolated, but as long as it's cleaning itself up, that's not a big deal.

> High level:  The flow is called and it looks at the c14n principal name from the profileContext that’s passed to it.

That won't work for pre-existing sessions, use the CanonicalPrincipalNameLookupStrategy function as a default to acquire the value, that handles both cases. That's what Duo uses.

-- Scott


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Developing login plugin

Joseph Fischetti
Thanks for the quick reply Scott,
Looks like the Duo documentation references CanonicalUsernameLookupStrategy
Is CanonicalPrincipalNameLookupStrategy different, or is that what you're referring to?

Something like this?
usernameLookupStrategy = new CanonicalUsernameLookupStrategy();
username = usernameLookupStrategy.apply(profileRequestContext);

Joe

Joe Fischetti
Linux System Administrator
Marist College

E-mail: [hidden email]

-----Original Message-----
From: dev <[hidden email]> On Behalf Of Cantor, Scott
Sent: Tuesday, November 19, 2019 10:12 AM
To: Shib Dev <[hidden email]>
Subject: Re: Developing login plugin

[EXTERNAL EMAIL]

On 11/19/19, 9:11 AM, "dev on behalf of Joseph Fischetti" <[hidden email] on behalf of [hidden email]> wrote:

> My question revolves around calling the attribute resolver, I’ve
> included some code below.  I currently have it working, but I want to make sure it’s working correctly based on the way the IdP is plumbed.

Mostly. I would stuff the contexts under the AuthenticationContext to keep them safely isolated, but as long as it's cleaning itself up, that's not a big deal.

> High level:  The flow is called and it looks at the c14n principal name from the profileContext that’s passed to it.

That won't work for pre-existing sessions, use the CanonicalPrincipalNameLookupStrategy function as a default to acquire the value, that handles both cases. That's what Duo uses.

-- Scott


--
To unsubscribe from this list send an email to [hidden email]

--
To unsubscribe from this list send an email to [hidden email]

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Developing login plugin

Cantor, Scott E.
On 11/19/19, 10:46 AM, "Joseph Fischetti" <[hidden email]> wrote:

> Looks like the Duo documentation references CanonicalUsernameLookupStrategy
> Is CanonicalPrincipalNameLookupStrategy different, or is that what you're referring to?

Yes, that's what I meant.

> Something like this?

It should be pluggable so a deployer can alter it, but as a default, yes.

-- Scott


--
To unsubscribe from this list send an email to [hidden email]