Configuring IdP v.2.3.8 with Silver assurance

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

Configuring IdP v.2.3.8 with Silver assurance

Terry Fleury
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:AuthenticationMethod>
  <ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</ph:AuthenticationMethod>
</ph:LoginHandler>

I also added an <Extensions> section to the IdP metadata with the
appropriate <AttributeValue> for silver.

This works fine for IdP v.2.2.1. I can request silver from my test SP
and the test IdP returns it when I log in with username/password.

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:

10:21:01.565 - ERROR
[edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:529]
- Relying patry required an authentication method of
[http://id.incommon.org/assurance/silver] but the login handler
performed urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
10:21:01.576 - ERROR
[edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:563]
- Authentication failed with the error:
edu.internet2.middleware.shibboleth.idp.authn.AuthenticationException:
Relying patry required an authentication method of
[http://id.incommon.org/assurance/silver] but the login handler
performed urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport

If the test SP does not request Silver, the test IdP gives
PasswordProtectedTransport as expected and the SP succeeds.

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?

Thank you for your help.

Terry Fleury
[hidden email]


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

Re: Configuring IdP v.2.3.8 with Silver assurance

Cantor, Scott E.
On 9/19/12 3:33 PM, "Terry Fleury" <[hidden email]> 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 [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 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
[hidden email]



On 9/19/2012 2:43 PM, Cantor, Scott wrote:

> On 9/19/12 3:33 PM, "Terry Fleury" <[hidden email]> 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 [hidden email]
>

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

Re: Configuring IdP v.2.3.8 with Silver assurance

Cantor, Scott E.
On 9/19/12 3:56 PM, "Terry Fleury" <[hidden email]> wrote:

>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.

I doubt it. I knew that this issue was going to bite people and that's why
I emphasized whenever possible that 2.3 was the baseline to work from.

>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.

I believe there are/where security issues in the 2.2 releases corrected in
2.3, and it's not going to get any future fixes. If all you have is a test
IdP, that's probably fine.

-- Scott


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

Re: Configuring IdP v.2.3.8 with Silver assurance

Terry Fleury
I decided to bite the bullet and try to get Silver assurance working
with Shibboleth Idp v.2.3.8. I managed to get it working for my
particular use case: UC2: SP Prefers Silver in
https://spaces.internet2.edu/display/InCAssurance/SP+Assurance+Policy+Use+Cases 
.

Basically, the SP first requests silver assurance. My SP does this by
passing "authnContextClassRef=http://id.incommon.org/assurance/silver"
to the login handler. If the IdP returns an error message (meaning that
it doesn't support silver), then the SP tries a second time, but this
time without the "authnContextClassRef" parameter.

On the IdP side, I had to make two configuration changes.

First, in web.xml (found in idp.war at WEB-INF/web.xml), I duplicated
the section commented as "<!-- Servlet for doing Username/Password
authentication -->", and modified it slightly. The copied section looks
like this:

     <!-- Servlet for doing Username/Password Silver authentication -->
     <servlet>
<servlet-name>UsernamePasswordSilverAuthHandler</servlet-name>
<servlet-class>edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginServlet</servlet-class>
         <load-on-startup>3</load-on-startup>
         <init-param>
           <param-name>authnMethod</param-name>
<param-value>http://id.incommon.org/assurance/silver</param-value>
         </init-param>
     </servlet>

     <servlet-mapping>
<servlet-name>UsernamePasswordSilverAuthHandler</servlet-name>
<url-pattern>/Authn/UserPasswordSilver</url-pattern>
     </servlet-mapping>

As you can see, I changed the <servlet-name> (in two places) and the
<url-pattern>, adding the word "Silver". Also, I added an <init-param>
section to return silver assurance by default.

Second, in conf/handler.xml, I uncommented the UsernamePassword
LoginHandler, duplicated it, and modified the copy to match the new
section in web.xml. The new section in handler.xml looks like this:

     <!--  Username/password Silver login handler -->
     <ph:LoginHandler xsi:type="ph:UsernamePassword"
jaasConfigurationLocation="file:///opt/shibboleth-idp/conf/login.config"
authenticationServletURL="/Authn/UserPasswordSilver">
<ph:AuthenticationMethod>http://id.incommon.org/assurance/silver</ph:AuthenticationMethod>
     </ph:LoginHandler>

Here I had to make two changes. First, I added the
"authenticationServletURL" parameter to match the <url-pattern> entry in
the web.xml file. Second, I set the AuthenticationMethod to silver to
match the <init-param> section in the web.xml.

This seems to work how I want it. When my test SP requests silver, the
IdP returns silver. When the SP requests nothing in particular, the IdP
returns PasswordProtectedTransport. In either case, the IdP presents the
user with the Username/Password login page. The login is authenticated
via Kerberos as configured in the login.config file.

I'm not sure this is the _correct_ way to do this, but this method was
done via configuration alone (rather than writing custom login handler),
so at least it was easy to implement.

Terry Fleury
[hidden email]


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

Re: Configuring IdP v.2.3.8 with Silver assurance

Cantor, Scott E.
On 9/26/12 4:23 PM, "Terry Fleury" <[hidden email]> wrote:
>
>I'm not sure this is the _correct_ way to do this, but this method was
>done via configuration alone (rather than writing custom login handler),
>so at least it was easy to implement.

That was how I believed it would work, but hadn't tried it. Each
individual UsernamePassword handler is locked to a single auth method
(that's the init parameter in web.xml, or defaults to the PPT value), but
you *can* define more than one using different servlet locations, each
supporting one method.

Obviously, you would have to have a way to limit the authentication that's
done to only the approach and the users that qualify for Silver.

Nice job, thanks.

Would you be willing to document that in either the project wiki or the
InCommon assurance wiki material in spaces? Probably the latter initially.

-- Scott


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

Re: Configuring IdP v.2.3.8 with Silver assurance

Tom Scavo
In reply to this post by Terry Fleury
On Wed, Sep 26, 2012 at 4:23 PM, Terry Fleury <[hidden email]> wrote:
> I decided to bite the bullet and try to get Silver assurance working
> with Shibboleth Idp v.2.3.8. I managed to get it working for my
> particular use case: UC2: SP Prefers Silver in
> https://spaces.internet2.edu/display/InCAssurance/SP+Assurance+Policy+Use+Cases

Great!

> This seems to work how I want it. When my test SP requests silver, the
> IdP returns silver. When the SP requests nothing in particular, the IdP
> returns PasswordProtectedTransport. In either case, the IdP presents the
> user with the Username/Password login page. The login is authenticated
> via Kerberos as configured in the login.config file.
>
> I'm not sure this is the _correct_ way to do this, but this method was
> done via configuration alone (rather than writing custom login handler),
> so at least it was easy to implement.

In practice this would be useful if ALL users and ALL authentications
in the IdP's security domain are equivalent. That probably won't turn
out to be the case very often but who knows. If the assumption is
true, however, why not just return silver in ALL cases (or I should
say, in both cases: silver and unspecified)?

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

Re: Configuring IdP v.2.3.8 with Silver assurance

Cantor, Scott E.
On 9/26/12 4:31 PM, "Tom Scavo" <[hidden email]> wrote:
>
>In practice this would be useful if ALL users and ALL authentications
>in the IdP's security domain are equivalent. That probably won't turn
>out to be the case very often but who knows. If the assumption is
>true, however, why not just return silver in ALL cases (or I should
>say, in both cases: silver and unspecified)?

That's just a PoC. You can always tie the different handlers to two
different JAAS config keys doing different things.

What you can't do with that alone is differentiate based on the individual
user via attributes or things like that.

-- Scott


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

Re: Configuring IdP v.2.3.8 with Silver assurance

Terry Fleury
In reply to this post by Tom Scavo

On 9/26/2012 3:31 PM, Tom Scavo wrote:

> On Wed, Sep 26, 2012 at 4:23 PM, Terry Fleury <[hidden email]> wrote:
>> I decided to bite the bullet and try to get Silver assurance working
>> with Shibboleth Idp v.2.3.8. I managed to get it working for my
>> particular use case: UC2: SP Prefers Silver in
>> https://spaces.internet2.edu/display/InCAssurance/SP+Assurance+Policy+Use+Cases
> Great!
>
>> This seems to work how I want it. When my test SP requests silver, the
>> IdP returns silver. When the SP requests nothing in particular, the IdP
>> returns PasswordProtectedTransport. In either case, the IdP presents the
>> user with the Username/Password login page. The login is authenticated
>> via Kerberos as configured in the login.config file.
>>
>> I'm not sure this is the _correct_ way to do this, but this method was
>> done via configuration alone (rather than writing custom login handler),
>> so at least it was easy to implement.
> In practice this would be useful if ALL users and ALL authentications
> in the IdP's security domain are equivalent. That probably won't turn
> out to be the case very often but who knows. If the assumption is
> true, however, why not just return silver in ALL cases (or I should
> say, in both cases: silver and unspecified)?

Returning silver for both cases (1. SP requests Silver and 2. SP
requests nothing special) is very simple. In that case, one would only
need to add the <init-param> section to the existing Username/Password
section in web.xml, and then change the <AuthenticationMethod> in
handler.xml from PasswordProtectedTransport to
http://id.incommon.org/assurance/silver. This was the first thing I
manage to get working during my tests. In this case, you are simply
changing the authentication method returned by the UsernamePassword
LoginHandler. From what I understand, the UsernamePassword LoginHandler
can return only one authenticationmethod, the default is
PasswordProtectedTransport. The <init-param> section can change the
method returned.

The particular use case I quoted was specific to the SP. But I wanted a
corresponding setup on the IdP side. In other words, if the IdP was
prompted to give silver, then give silver. If the Idp was NOT prompted
to give silver, then give the default PasswordProtectedTransport.

In my time on the InCommon assurance calls, I always took the point of
view of the SP. This is the first time I've worked on the IdP side. I
admit that I haven't considered the various use cases for the IdP, and I
certainly don't claim to have expert knowledge of how IdPs work. I guess
this was just more of an exercise to see if I could get shib idp v.2.3.x
to behave how I had configured my test idp v.2.2.1.

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

Re: Configuring IdP v.2.3.8 with Silver assurance

Terry Fleury
In reply to this post by Cantor, Scott E.
Yes, I think the InCommon assurance wiki would probably be a good place
for it now. Not sure if there is an existing page where it should go, or
if I should create a new page.

I guess I'll make a new page and put a link on
https://spaces.internet2.edu/display/InCAssurance/Community+Contributions ,
maybe under a new "Examples" section.

Terry Fleury
[hidden email]

On 9/26/2012 3:27 PM, Cantor, Scott wrote:

> On 9/26/12 4:23 PM, "Terry Fleury" <[hidden email]> wrote:
>> I'm not sure this is the _correct_ way to do this, but this method was
>> done via configuration alone (rather than writing custom login handler),
>> so at least it was easy to implement.
> That was how I believed it would work, but hadn't tried it. Each
> individual UsernamePassword handler is locked to a single auth method
> (that's the init parameter in web.xml, or defaults to the PPT value), but
> you *can* define more than one using different servlet locations, each
> supporting one method.
>
> Obviously, you would have to have a way to limit the authentication that's
> done to only the approach and the users that qualify for Silver.
>
> Nice job, thanks.
>
> Would you be willing to document that in either the project wiki or the
> InCommon assurance wiki material in spaces? Probably the latter initially.
>
> -- Scott
>
>
> --
> To unsubscribe from this list send an email to [hidden email]
>

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

Re: Configuring IdP v.2.3.8 with Silver assurance

Terry Fleury
I have created a new page under
https://spaces.internet2.edu/display/InCAssurance/Community+Contributions entitled
"IdP Configuration for Username-Password with Silver Assurance". Please
move/modify as you see fit.

Terry Fleury
[hidden email]

On 9/26/2012 3:49 PM, Terry Fleury wrote:

> Yes, I think the InCommon assurance wiki would probably be a good
> place for it now. Not sure if there is an existing page where it
> should go, or if I should create a new page.
>
> I guess I'll make a new page and put a link on
> https://spaces.internet2.edu/display/InCAssurance/Community+Contributions 
> , maybe under a new "Examples" section.
>
> Terry Fleury
> [hidden email]
>
> On 9/26/2012 3:27 PM, Cantor, Scott wrote:
>> On 9/26/12 4:23 PM, "Terry Fleury" <[hidden email]> wrote:
>>> I'm not sure this is the _correct_ way to do this, but this method was
>>> done via configuration alone (rather than writing custom login
>>> handler),
>>> so at least it was easy to implement.
>> That was how I believed it would work, but hadn't tried it. Each
>> individual UsernamePassword handler is locked to a single auth method
>> (that's the init parameter in web.xml, or defaults to the PPT value),
>> but
>> you *can* define more than one using different servlet locations, each
>> supporting one method.
>>
>> Obviously, you would have to have a way to limit the authentication
>> that's
>> done to only the approach and the users that qualify for Silver.
>>
>> Nice job, thanks.
>>
>> Would you be willing to document that in either the project wiki or the
>> InCommon assurance wiki material in spaces? Probably the latter
>> initially.
>>
>> -- Scott
>>
>>
>> --
>> To unsubscribe from this list send an email to
>> [hidden email]
>>
>

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

Re: Configuring IdP v.2.3.8 with Silver assurance

Tom Scavo
On Wed, Sep 26, 2012 at 6:28 PM, Terry Fleury <[hidden email]> wrote:
> I have created a new page under
> https://spaces.internet2.edu/display/InCAssurance/Community+Contributions entitled
> "IdP Configuration for Username-Password with Silver Assurance". Please
> move/modify as you see fit.

Thank you, Terry!

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