External Authentication setup issues.

[PARDEE, MARTIN (MARTIN)]

These are VERY helpful points Chad.  I'm going to go back and review what I've done so far and weed out the un-necessary changes.


Thanks so much for your patience and advice.


Martin


-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Chad La Joie
Sent: Wednesday, May 16, 2012 12:51 PM
To: Shib Users
Subject: Re: External Authentication setup issues.

On Wed, May 16, 2012 at 11:21 AM, PARDEE, MARTIN  (MARTIN)
<mlp at research.att.com> wrote:
>  I believe that I have done all of the steps I need to engage my custom authenticator class,  but I think that there must be a missing piece. Once I have made my custom class/servlet available to the IdP via a handler.xml handler entry,  how to I tell the IdP that an incoming request for authentication from an SP should USE this handler?

There are three ways to signal this:
1. Make it the only login handler available (i.e., comment out the
other ones).  This obviously doesn't work if you have to support
multiple methods
2. In the relying-party.xml, on a relying party configuration you can
configure the default authentication method
3. Have the SP request the handler by the authentication method ID you
assign it.

> One thing that bothers me about these sample projects it that the authors suggest running the shibboleth "install.sh" script as the way to put their authentication extensions into effect. I am reluctant to do this as I believe it will over-write my existing metadata and handler.xml files. And this is where I start to feel _very_ uncertain of my understanding of the way shib works.

The install script ensures that the extension gets installed in to the
two places it needs to go; i.e. IDP_HOME/lib and in the WAR.

> It seems to me that web.xml is where I need to go to plug in my custom "authenticator-invoker" class.

Well, changing the web.xml is only required if you need to actually
add servlets/filters.  If you're using the external authn handler that
may or not be the case.  It really depends on how and where you
implement your authn logic.

> It also seems that handler.xml is where I need to tell the IdP that there is a URL to use for an operation of type "ExternalAuthn".

Yes, you need to configure the external authentication login handler
as described in the documentation, including telling it where to send
people when that authentication mechanism is invoked.

> But I don't see a place where I can tell the IdP that an incoming request from a given SP should _use_ this new type of authn to resolve the user's identity. I would have guessed that it was necessary to make a change either in relying-party.xml or in the idp-metadata.xml file (also shared by the SP) so that _some_ statement of intent for the authentication mechanism is declared.

Right, I discussed that above.  You would change the relying-party.xml
if you opted for option 2.  If not you wouldn't.  In no case do you
change the metadata.


> I have gone to the oasis site where these URNs are defined,  and "Telephony" is the closest match I can see to what it is my authenticator does,  but I have NO IDEA what using that URN would mean to my shibboleth IdP.

That URI is totally up to you.  The IdP just does a string match on
it.  So create a URI for your custom method and use that.

>
>  The documentation at : https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthExternal doesn't mention any changes to relying-party.xml or
>  to the metadata or to the other config files. This puzzles me.

Because changes to those files aren't related to installing or
configuring the mechanism.

-- 
Chad La Joie
www.itumi.biz
trusted identities, delivered
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net