Shibboleth Developers

[Chad La Joie <>]

You're up late.

Yeah, if you need to do request routing and the like then you'll need a
custom login handler.  You may have a problem with what you describe if
the SP requests both forced and passive authentication.  You can get at
this information through the LoginContext, available to the handler.

In terms of the authentication method, the login handler is capable of
reporting back to the AuthN engine what method was used.  Currently
there is a small issue with the IdP.  If an SP requires a particular
method, say OTP, and a login handler is chosen that supports that method
but in turn returns something other method, say Username/Pass, the IdP
does not detect this an error.  In the next release it will but I need
to make a small change to the LoginContext API to expose an extra bit of
data to detect this situation.

Jim Fox wrote:
> 
> We use pubcookie in front of our IdP, and I'd like to implement some of
> the login options supported by shib 2.1.
> 
> 1) isPassive and forceAuthn:  pubcookie supports these most easily if we
> use different authn urls for each.  Is a custom login handler, along the
> lines of the distributed RemoteUser handler, the right way to go.  It
> would act much like RemoteUser, but make allowances for the passive and
> forceAuthn flags -- redirecting to different login urls for each.
> 
> 2) SecureID:  pubcookie supports this also, with a distinct authn ur l
> to trigger securid login.  Is this a proper use of  authnContextClassRef
> ?  If so, is there a way to communicate 'secureid' to the handler in
> (1)?  or should I implement a separate login handler for this?
> 
> Jim
> 
> 

-- 
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Net Services
Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
,
 http://www.switch.ch