External Authentication setup issues.

[PARDEE, MARTIN (MARTIN)]

Chad,


 Thanks for responding to my email so quickly.

 As you can see from my previous email.  I have gone the route of "External Handler".

 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? The community-provided example projects for x509 and multi-factor auth , which I have looked at, have not as yet given me the key to success. I have been able to read their project code,  but not use it since I have a Windows 7 SP and not apache. 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. 

It seems to me that web.xml is where I need to go to plug in my custom "authenticator-invoker" class.  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". 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. 


For a Username-Password authentication,  my relying party declaration for my particular SP has an attribute line that looks like this:

  defaultAuthenticationMethod="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport"


It seems to me that I need to have an entry in relying party for this same SP that substitutes "PasswordProtectedTransport" with something else.
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.


 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.

 I haven't made any changes to the UsernamePassword attributes found in existing xml files.  Perhaps the things that need to change are so obvious
 to an experienced Shibboleth developer that you wouldn't think to question it.  But I feel I've left out some fundamental piece of the puzzle.

 So..

 Even though I have  a new handler, and a servlet doing custom work for that handler,  I still haven't told the IdP WHO needs this service and
 HOW to invoke it. Is there some config that needs to be set up for external auth _besides_ changes to handler.xml and to the web.xml file?


Best regards,

 Martin Pardee
mlp at research.att.com



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

If you're looking to integrate a new authentication mechanism you have
a couple of options.  The easiest, if you can do it, is to have the
container (Apache, Tomcat, Jetty, etc.) do the authentication and set
the REMOTE_USER information.  Then use the REMOTE_USER login handler.

Option two is to use the external authentication handler.  The
external authentication handler hands off control to a URL that you
provide.  What goes on after the handoff occurs is totally up to you
and you can do anything you can program.  When your code is done doing
it's thing it has to pass control back to the IdP per the
documentation.

Option three is to write you own login handler.  This requires the
most effort but allows you the most flexibility.  The documentation of
how to write a login handler is also documented.

Note, none of these options has anything to with the username/password
login handler or JAAS.

On Tue, May 15, 2012 at 5:43 PM, PARDEE, MARTIN  (MARTIN)
<mlp at research.att.com> wrote:
> Folks:
>
>
>
> I'm attempting to use an external auth engine on my idp.  I have a service
> that uses voice to authenticate a user, and it is activate via a call to a
> restful web interface.
>
>
>
> I have followed the instructions found here:
> https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthExternal,
>
>
>
> I have a class, in a jar file, placed in the idp project's WEB-INF/lib
> directory. This class is patterned after the UserPasswordLoginHandler class
> in order to get the interface to the AuthEngine right..
>
>
>
>
>
> I have modified the idp project's web.xml file to include a definition for
> the servlet, based on that class.
>
>
>
> I have modified my handler.xml file to use a LoginHandler definition that
> refers to the URL for this servlet.
>
>
>
> When this is all assembled and the servers restarted, I always get to the
> UsernamePassword login (if there's no active SSO session still in effect).
>
>
>
> I suspect that I need to make some kind of addition or mod to the
> information in the JAAS configuration file, login.config, but the
> instructions on this page don't suggest that.
>
>
>
> I've examined the community-contributed examples for x509 auth and
> multi-factor auth, and there are enough differences between these projects
> and my own, that I get more confused about what is expected. These projects
> delve into modifying the login.config (which is where I got the idea from)
> and the xsd schema.
>
>
>
> Please, I could really use some guidance on what the bare necessities are
> for integrating a new external authentication class into the shibboleth
> frame work are. I am beginning to think that my only recourse is going to be
> downloading the source and hacking it locally.  This seems like an extremely
> bad idea, and I can't believe that trying to use a published extension is
> really this hard. I MUST be missing something.
>
>
>
>
>
> Thanks for listening to me vent.
>
>
>
>
>
> Martin Pardee
>
>
>
>
>
> mlp at research.att.com
>
>
>
>
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net



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