Configuring IdP v.2.3.8 with Silver assurance

[Terry Fleury]

Thanks for the quick response Scott.

I suspect that I am one of the few (only?) people wanting to do 
UsernamePassword + Kerberos + Silver. I assume that most schools have a 
more complex authentication scheme which they can modify to return 
silver if requested.

At this point, I use the test IdP very rarely, so spending a lot of time 
writing a custom login handler just for 2.3.8 + silver doesn't interest 
me. I guess I'll stick with the (incorrect) v.2.2.1 configuration until 
I decide I need a feature of 2.3.8.

Thanks for the useful info.

Terry Fleury
tfleury at illinois.edu



On 9/19/2012 2:43 PM, Cantor, Scott wrote:
> On 9/19/12 3:33 PM, "Terry Fleury" <tfleury at illinois.edu> wrote:
>
>> Hello,
>>
>> To date, I have been using Shibboleth IdP software v.2.2.1 on my test
>> IdP. The IdP is configured to use the UsernamePassword <LoginHandler>
>> backed by JAAS/Kerberos authentication. To get it to also use silver
>> assurance, I added an <AuthenticationMethod> statement in the
>> <LoginHandler> as follows:
>>
>> <ph:LoginHandler xsi:type="ph:UsernamePassword"
>> jaasConfigurationLocation="file:///opt/shibboleth-idp/conf/login.config">
>>   
>> <ph:AuthenticationMethod>http://id.incommon.org/assurance/silver</ph:Authe
>> nticationMethod>
>>   
>> <ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordPr
>> otectedTransport</ph:AuthenticationMethod>
>> </ph:LoginHandler>
> In practice, you can't do that. Fixing various bugs in 2.3 resulted in
> locking the built-in plugins to a single authentication method which is
> configurable for the handler. So if you want a handler that really
> supports more than one, you need more than one handler, or a custom
> handler.
>
> This isn't a regression, but a bug fix, to prevent attacks where the
> request was for X but the handler is manipulated to assert back Y where Y
> < X.
>
>> A similar configuration does NOT work for IdP v.2.3.8. When my test SP
>> requests silver, I get the following error in the idp-process.log file:
> Because the default method the handler is assuming it's responsible for is
> the PPT method, so asking for Silver breaks it when it asserts back PPT
> and the IdP detects the mismatch.
>
>> I understand IdP v.2.3.x is more particular with placement of
>> configuration options. So how can I make IdP v.2.3.8 act like v.2.2.1,
>> i.e., return silver assurance when requested from the SP?
> You can't, modulo changing the handlers in number and/or composition. None
> of the built-in handlers knows how to handle multiple types internally,
> even if mechanically you can associate more than one method with them.
>
> I used to think, though, that you couldn't actually have multiple
> UsernamePassword handlers configured. If that was true at some point, I
> think it's not true now. So one option is having separate plugins of that
> same type for the two methods.
>
> I also don't know the name of the property that tells the handler what
> method it's meant to assert back to the IdP, but I know that it's
> configurable and is not limited to PPT.
>
> I suspect various other things have to change. You'd need the JAAS config
> to include multiple config sections, and then specify which one to use in
> the handler. And probably different servlet paths for the second handler
> with attendant changes to web.xml. All doable, just a bit of work.
>
> Custom handlers, however, are free to assert back whatever methods they
> wish to, so they can evaluate the SAML request and then decide how to do
> things. Then as long as the IdP gets back a matching value, it's happy.
>
> -- Scott
>
>
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
>