Integrating IdP with Database or File Store

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

Integrating IdP with Database or File Store

Mihai Danila

Hi,

I'm trying to set up a Shibboleth IdP and SP, attempting to test them  
together. I can't figure out how to use a file that contains user  
credentials, or even a relational database. The feature doesn't seem  
to be there. We don't use LDAP and sure as hell don't use Kerberos, so  
is there a way for me to cut short a day of frustration and finally  
set up something functional? I'm reading the documents, but for some  
reason they all fall short.

Having a walkthrough that helps one set up Shibboleth with a file  
based user credential store would prove instrumental in understanding  
the mechanics of the two products.


Thanks,
Mihai Danila


Reply | Threaded
Open this post in threaded view
|

Re: Integrating IdP with Database or File Store

Michael J. Wheeler
If you want to remove the login/password from the equation and just focus on "what happens once a user is authenticated", have you looked at the IPAddress login handler? Basically, if the user is coming from a particular IP address, then they're automatically authenticated as a pre-defined user.

See here: https://spaces.internet2.edu/display/SHIB2/IdPAuthIP

You may also look at the RemoteUser login handler. If you can whip up a quick PHP script that sets the "REMOTE_USER" HTTP header, then forwards you on, you can simulate an authenticated session.

See here: https://spaces.internet2.edu/display/SHIB2/IdPAuthIP

Both should be fairly simple to set up in a test environment.

--
Michael J. Wheeler
Assistant Director, Systems and Networking
Pittsburg State University
Phone:  620-235-4610
E-mail: [hidden email]

----- Original Message -----
From: "Mihai Danila" <[hidden email]>
To: [hidden email]
Sent: Wednesday, January 21, 2009 2:44:17 PM GMT -06:00 US/Canada Central
Subject: [Shib-Users] Integrating IdP with Database or File Store


Hi,

I'm trying to set up a Shibboleth IdP and SP, attempting to test them  
together. I can't figure out how to use a file that contains user  
credentials, or even a relational database. The feature doesn't seem  
to be there. We don't use LDAP and sure as hell don't use Kerberos, so  
is there a way for me to cut short a day of frustration and finally  
set up something functional? I'm reading the documents, but for some  
reason they all fall short.

Having a walkthrough that helps one set up Shibboleth with a file  
based user credential store would prove instrumental in understanding  
the mechanics of the two products.


Thanks,
Mihai Danila


Reply | Threaded
Open this post in threaded view
|

Re: Integrating IdP with Database or File Store

Mihai Danila

Thank you for the pointers. IP authentication can help with setting up  
most of the moving parts. It doesn't, however, indicate how the IdP  
might query a data store to produce its assertion, or how it might  
integrate with an existing application's login page.

Regarding the PHP script, I don't see how it fits into the picture. I  
suspect there's an AuthenticationMethod in which the IdP displays a  
webpage to the user, webpage that posts credentials back to the IdP?  
I'm definitely missing a few steps here.

I wonder if I'm reading the wrong docs. Maybe I should start with the  
SAML spec, but that seems pretty involved and would eat up a lot of my  
time.


Mihai


On Jan 21, 2009, at 3:55 PM, Michael J. Wheeler wrote:

> If you want to remove the login/password from the equation and just  
> focus on "what happens once a user is authenticated", have you  
> looked at the IPAddress login handler? Basically, if the user is  
> coming from a particular IP address, then they're automatically  
> authenticated as a pre-defined user.
>
> See here: https://spaces.internet2.edu/display/SHIB2/IdPAuthIP
>
> You may also look at the RemoteUser login handler. If you can whip  
> up a quick PHP script that sets the "REMOTE_USER" HTTP header, then  
> forwards you on, you can simulate an authenticated session.
>
> See here: https://spaces.internet2.edu/display/SHIB2/IdPAuthIP
>
> Both should be fairly simple to set up in a test environment.
>
> --
> Michael J. Wheeler
> Assistant Director, Systems and Networking
> Pittsburg State University
> Phone:  620-235-4610
> E-mail: [hidden email]
>
> ----- Original Message -----
> From: "Mihai Danila" <[hidden email]>
> To: [hidden email]
> Sent: Wednesday, January 21, 2009 2:44:17 PM GMT -06:00 US/Canada  
> Central
> Subject: [Shib-Users] Integrating IdP with Database or File Store
>
>
> Hi,
>
> I'm trying to set up a Shibboleth IdP and SP, attempting to test them
> together. I can't figure out how to use a file that contains user
> credentials, or even a relational database. The feature doesn't seem
> to be there. We don't use LDAP and sure as hell don't use Kerberos, so
> is there a way for me to cut short a day of frustration and finally
> set up something functional? I'm reading the documents, but for some
> reason they all fall short.
>
> Having a walkthrough that helps one set up Shibboleth with a file
> based user credential store would prove instrumental in understanding
> the mechanics of the two products.
>
>
> Thanks,
> Mihai Danila
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Integrating IdP with Database or File Store

Peter Schober
In reply to this post by Mihai Danila
* Mihai Danila <[hidden email]> [2009-01-21 21:44]:
> We don't use LDAP and sure as hell don't use Kerberos, so is there a
> way for me to cut short a day of frustration and finally set up
> something functional? I'm reading the documents, but for some reason
> they all fall short.

Besides the IPAddress and RemoteUser handler, which already have been
suggested, you could use the JAAS module for flatfiles from
Tagish. (That's not a "walkthrough" of course, just a hint to feed to
your favorite search engine.)
Also this has been covered on this list recently, so also check the
archives.

cheers,
-peter

--
[hidden email] - vienna university computer center
Universitaetsstrasse 7, A-1010 Wien, Austria/Europe
Tel. +43-1-4277-14155, Fax. +43-1-4277-9140
Reply | Threaded
Open this post in threaded view
|

Re: Integrating IdP with Database or File Store

Peter Schober
In reply to this post by Mihai Danila
* Mihai Danila <[hidden email]> [2009-01-21 22:06]:
> I wonder if I'm reading the wrong docs. Maybe I should start with
> the SAML spec, but that seems pretty involved and would eat up a lot
> of my time.

Maybe start in the Shib wiki at
https://spaces.internet2.edu/display/SHIB2/Home
which among other things suggests:

"For more information please read"
https://spaces.internet2.edu/display/SHIB2/UnderstandingShibboleth

cheers,
-peter
Reply | Threaded
Open this post in threaded view
|

Re: Integrating IdP with Database or File Store

Paul Hethmon
In reply to this post by Mihai Danila
Re: [Shib-Users] Integrating IdP with Database or File Store Mihai,

Shibboleth doesn’t really care how a user is authenticated, it’s outside the scope of the SAML spec. So what happens is you plug-in a method. In my case, I’m talking to the Safemls server at RMLS-MN, so that’s the IdP I’ve set up there. What Shib and SAML care about is the information passed back to the Service Provider (SP, also known as Relying Party or RP). Based on how Shib is configured, you will get back some sort of ID for the user that authenticated. That information can be sent as part of the Subject of the assertion or as attributes. In my case, I’m going to send it to you as part of the Subject. When using Shib SP, it will read that information, whether via Subject or attributes, and make it available to your web application via HTTP server variables. So if your application gets a page request, you know that the user is authenticated and that the login ID (again, specific to the RMLS-MN installation) will be in the HTTP_REMOTE_USER server variable. At that point, you simply take that value and do any normal processing you would do based on the login ID. The only thing you don’t do is check a password or other credential, you don’t get them, nor do you need them.

If you need a local working Shib IdP,  the simplest to implement is a JAAS module. All you have to do is write one and configure Shib to use it. JAAS is a Java standard interface and I think Shib has a skeleton for one included.

Paul


On 1/21/09 4:06 PM, "Mihai Danila" <mihai@...> wrote:



Thank you for the pointers. IP authentication can help with setting up
most of the moving parts. It doesn't, however, indicate how the IdP
might query a data store to produce its assertion, or how it might
integrate with an existing application's login page.

Regarding the PHP script, I don't see how it fits into the picture. I
suspect there's an AuthenticationMethod in which the IdP displays a
webpage to the user, webpage that posts credentials back to the IdP?
I'm definitely missing a few steps here.

I wonder if I'm reading the wrong docs. Maybe I should start with the
SAML spec, but that seems pretty involved and would eat up a lot of my
time.


Mihai


On Jan 21, 2009, at 3:55 PM, Michael J. Wheeler wrote:

> If you want to remove the login/password from the equation and just
> focus on "what happens once a user is authenticated", have you
> looked at the IPAddress login handler? Basically, if the user is
> coming from a particular IP address, then they're automatically
> authenticated as a pre-defined user.
>
> See here: https://spaces.internet2.edu/display/SHIB2/IdPAuthIP
>
> You may also look at the RemoteUser login handler. If you can whip
> up a quick PHP script that sets the "REMOTE_USER" HTTP header, then
> forwards you on, you can simulate an authenticated session.
>
> See here: https://spaces.internet2.edu/display/SHIB2/IdPAuthIP
>
> Both should be fairly simple to set up in a test environment.
>
> --
> Michael J. Wheeler
> Assistant Director, Systems and Networking
> Pittsburg State University
> Phone:  620-235-4610
> E-mail: mwheeler@...
>
> ----- Original Message -----
> From: "Mihai Danila" <mihai@...>
> To: shibboleth-users@...
> Sent: Wednesday, January 21, 2009 2:44:17 PM GMT -06:00 US/Canada
> Central
> Subject: [Shib-Users] Integrating IdP with Database or File Store
>
>
> Hi,
>
> I'm trying to set up a Shibboleth IdP and SP, attempting to test them
> together. I can't figure out how to use a file that contains user
> credentials, or even a relational database. The feature doesn't seem
> to be there. We don't use LDAP and sure as hell don't use Kerberos, so
> is there a way for me to cut short a day of frustration and finally
> set up something functional? I'm reading the documents, but for some
> reason they all fall short.
>
> Having a walkthrough that helps one set up Shibboleth with a file
> based user credential store would prove instrumental in understanding
> the mechanics of the two products.
>
>
> Thanks,
> Mihai Danila
>
>





-----
Paul Hethmon
Chief Software Architect
Clareity Security, LLC
865.824.1350 - office
865.250.3517 - mobile
www.clareitysecurity.com
-----

Give a man a fire and he's warm for the day. But set fire to him and he's warm for the rest of his life.

 -- Terry Pratchett, Discworld

Reply | Threaded
Open this post in threaded view
|

Re: Integrating IdP with Database or File Store

Mihai Danila
In reply to this post by Peter Schober

Hi Paul,

Thank you. That was one of my first reads.

I read most configuration related articles; I also looked at  
troubleshooting (pretty slim, anyway -- if you get a crash, don't  
despair).

"Shibbolizing an application" was another of my reads; but while it  
features links to scripts that a Shib-aware application may use, it  
doesn't say what configuration option in the IdP must be actuated in  
order to make the link to the application. Maybe the information is  
somewhere in that wiki, but it seems removed from the context. I hope  
it's not going to be found in any Attributes-related article, as I  
assumed attributes are optional I can safely skip those for the  
purposes of basic setup.

Yet another piece of information that seem to be missing or removed  
from the location that one would expect them found in include:
What URL the Shibboleth SP publishes its metadata as. (I'm sure  
sufficient googling or a find-in-files will eventually unveil this.)

I still think the walkthrough would be an important addition. And once  
I get to the bottom of this, I may write a quick one myself and push  
it into the mailing list.


Mihai



On Jan 21, 2009, at 4:11 PM, Peter Schober wrote:

> * Mihai Danila <[hidden email]> [2009-01-21 22:06]:
>> I wonder if I'm reading the wrong docs. Maybe I should start with
>> the SAML spec, but that seems pretty involved and would eat up a lot
>> of my time.
>
> Maybe start in the Shib wiki at
> https://spaces.internet2.edu/display/SHIB2/Home
> which among other things suggests:
>
> "For more information please read"
> https://spaces.internet2.edu/display/SHIB2/UnderstandingShibboleth
>
> cheers,
> -peter

Reply | Threaded
Open this post in threaded view
|

RE: Integrating IdP with Database or File Store

Cantor, Scott E.
In reply to this post by Mihai Danila
Mihai Danila wrote on 2009-01-21:
>
> Thank you for the pointers. IP authentication can help with setting up
> most of the moving parts. It doesn't, however, indicate how the IdP
> might query a data store to produce its assertion,

https://spaces.internet2.edu/display/SHIB2/IdPAddAttribute
https://spaces.internet2.edu/display/SHIB2/ResolverRDBMSDataConnector

> or how it might
> integrate with an existing application's login page.

Web applications either get authentication from the web server seamlessly
already, in which case very little has to change, or they have to be hacked
up to rely on Shibboleth, usually by converting the existing login page into
a stub protected by the SP that gateways the user into the app.

All of your authentication, SAML or otherwise, should be isolated from the
application such that there is no login page inside it.

Such discusson has nothing to do with the software and everything to do with
proper web design that's beyond the scope of its documentation. Like many
such topics, there's a huge need for the information, and a huge shortage of
people willing to write it. For that matter, there's a profound shortage of
people to write the walkthrough you want too.
 
> Regarding the PHP script, I don't see how it fits into the picture. I
> suspect there's an AuthenticationMethod in which the IdP displays a
> webpage to the user, webpage that posts credentials back to the IdP?
> I'm definitely missing a few steps here.

https://spaces.internet2.edu/display/SHIB2/IdPUserAuthn

> I wonder if I'm reading the wrong docs. Maybe I should start with the
> SAML spec, but that seems pretty involved and would eat up a lot of my
> time.

While I personally feel reading at least the tech overview is simply due
diligence, none of your questions so far would be addressed by it as they're
out of scope.

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: Integrating IdP with Database or File Store

Cantor, Scott E.
In reply to this post by Mihai Danila
Mihai Danila wrote on 2009-01-21:
> "Shibbolizing an application" was another of my reads; but while it
> features links to scripts that a Shib-aware application may use, it
> doesn't say what configuration option in the IdP must be actuated in
> order to make the link to the application.

Because there isn't one in general. The SP is responsible for making the
authentication requests. The IdP configuration controls what happens when it
gets one.

> Maybe the information is
> somewhere in that wiki, but it seems removed from the context. I hope
> it's not going to be found in any Attributes-related article, as I
> assumed attributes are optional I can safely skip those for the
> purposes of basic setup.

You can set up an IdP without attributes, but not without changing defaults
to make the identifier it provides mean something (and be visible at the
SP). Those changes will be profoundly confusing so this is not a good way to
go.

> Yet another piece of information that seem to be missing or removed
> from the location that one would expect them found in include:

I'd be interested to know "the location one would expect them"?

> What URL the Shibboleth SP publishes its metadata as.

An SP normally does not host its own metadata. It can generate metadata as a
help for federation enrollment or testing, but it is not advisable to
directly consume that in real-time or at the URL it happens to come from.
The generation process is at /Shibboleth.sso/Metadata but if an SP were to
hosts its metadata, the location at which it should do so is its entityID.

> I still think the walkthrough would be an important addition. And once
> I get to the bottom of this, I may write a quick one myself and push
> it into the mailing list.

Documentation is welcome, but in the wiki, not the list.
 
-- Scott


Reply | Threaded
Open this post in threaded view
|

Re: Integrating IdP with Database or File Store

Mihai Danila
In reply to this post by Paul Hethmon

Oh, hi Paul. Good to see you here.

Yes, I am trying to set up IdP as part of my testing here. I'm thinking that, at the very least, Shibboleth IdP will present the user with a webpage produced by whatever authentication module it delegates authentication to. (That web page would post back to the IdP, or at least that's what the SAML diagrams I've seen around suggest.) Or does Shibboleth present its own webpage with a username field and a credential field and then obliviously plugs these into the module? How that webpage comes about is part of that missing information. I'll do some more reading.

(If there's a feeling that our conversation will not benefit the list, I can make future "data packets" private.)

On Jan 21, 2009, at 4:20 PM, Paul Hethmon wrote:

Mihai,

Shibboleth doesn’t really care how a user is authenticated, it’s outside the scope of the SAML spec. So what happens is you plug-in a method. In my case, I’m talking to the Safemls server at RMLS-MN, so that’s the IdP I’ve set up there. What Shib and SAML care about is the information passed back to the Service Provider (SP, also known as Relying Party or RP). Based on how Shib is configured, you will get back some sort of ID for the user that authenticated. That information can be sent as part of the Subject of the assertion or as attributes. In my case, I’m going to send it to you as part of the Subject. When using Shib SP, it will read that information, whether via Subject or attributes, and make it available to your web application via HTTP server variables. So if your application gets a page request, you know that the user is authenticated and that the login ID (again, specific to the RMLS-MN installation) will be in the HTTP_REMOTE_USER server variable. At that point, you simply take that value and do any normal processing you would do based on the login ID. The only thing you don’t do is check a password or other credential, you don’t get them, nor do you need them.

If you need a local working Shib IdP,  the simplest to implement is a JAAS module. All you have to do is write one and configure Shib to use it. JAAS is a Java standard interface and I think Shib has a skeleton for one included.

Paul


On 1/21/09 4:06 PM, "Mihai Danila" <mihai@...> wrote:



Thank you for the pointers. IP authentication can help with setting up
most of the moving parts. It doesn't, however, indicate how the IdP
might query a data store to produce its assertion, or how it might
integrate with an existing application's login page.

Regarding the PHP script, I don't see how it fits into the picture. I
suspect there's an AuthenticationMethod in which the IdP displays a
webpage to the user, webpage that posts credentials back to the IdP?
I'm definitely missing a few steps here.

I wonder if I'm reading the wrong docs. Maybe I should start with the
SAML spec, but that seems pretty involved and would eat up a lot of my
time.


Mihai


On Jan 21, 2009, at 3:55 PM, Michael J. Wheeler wrote:

> If you want to remove the login/password from the equation and just
> focus on "what happens once a user is authenticated", have you
> looked at the IPAddress login handler? Basically, if the user is
> coming from a particular IP address, then they're automatically
> authenticated as a pre-defined user.
>
> See here: https://spaces.internet2.edu/display/SHIB2/IdPAuthIP
>
> You may also look at the RemoteUser login handler. If you can whip
> up a quick PHP script that sets the "REMOTE_USER" HTTP header, then
> forwards you on, you can simulate an authenticated session.
>
> See here: https://spaces.internet2.edu/display/SHIB2/IdPAuthIP
>
> Both should be fairly simple to set up in a test environment.
>
> --
> Michael J. Wheeler
> Assistant Director, Systems and Networking
> Pittsburg State University
> Phone:  620-235-4610
> E-mail: mwheeler@...
>
> ----- Original Message -----
> From: "Mihai Danila" <mihai@...>
> To: shibboleth-users@...
> Sent: Wednesday, January 21, 2009 2:44:17 PM GMT -06:00 US/Canada
> Central
> Subject: [Shib-Users] Integrating IdP with Database or File Store
>
>
> Hi,
>
> I'm trying to set up a Shibboleth IdP and SP, attempting to test them
> together. I can't figure out how to use a file that contains user
> credentials, or even a relational database. The feature doesn't seem
> to be there. We don't use LDAP and sure as hell don't use Kerberos, so
> is there a way for me to cut short a day of frustration and finally
> set up something functional? I'm reading the documents, but for some
> reason they all fall short.
>
> Having a walkthrough that helps one set up Shibboleth with a file
> based user credential store would prove instrumental in understanding
> the mechanics of the two products.
>
>
> Thanks,
> Mihai Danila
>
>





-----
Paul Hethmon
Chief Software Architect
Clareity Security, LLC
865.824.1350 - office
865.250.3517 - mobile
www.clareitysecurity.com
-----

Give a man a fire and he's warm for the day. But set fire to him and he's warm for the rest of his life.

 -- Terry Pratchett, Discworld


Reply | Threaded
Open this post in threaded view
|

Re: Integrating IdP with Database or File Store

Mihai Danila
In reply to this post by Cantor, Scott E.

Hi Scott,

My comments are inline.

On Jan 21, 2009, at 4:35 PM, Scott Cantor wrote:

> Mihai Danila wrote on 2009-01-21:
>> "Shibbolizing an application" was another of my reads; but while it
>> features links to scripts that a Shib-aware application may use, it
>> doesn't say what configuration option in the IdP must be actuated in
>> order to make the link to the application.
>
> Because there isn't one in general. The SP is responsible for making  
> the
> authentication requests. The IdP configuration controls what happens  
> when it
> gets one.
>

In order to shibbolize an application, both use cases (request  
authentication and process an assertion, or something that comes into  
the application from the SP as a result of an assertion) must be taken  
into account. My feeling is that both should be presented in the  
article.

>> Maybe the information is
>> somewhere in that wiki, but it seems removed from the context. I hope
>> it's not going to be found in any Attributes-related article, as I
>> assumed attributes are optional I can safely skip those for the
>> purposes of basic setup.
>
> You can set up an IdP without attributes, but not without changing  
> defaults
> to make the identifier it provides mean something (and be visible at  
> the
> SP). Those changes will be profoundly confusing so this is not a  
> good way to
> go.

I understand that the basic web browser profile can be used to  
successfully authenticate users and the SP and IdP don't have to  
communicate.

>
>
>> Yet another piece of information that seem to be missing or removed
>> from the location that one would expect them found in include:
>
> I'd be interested to know "the location one would expect them"?

In "Shibbolizing an application." I find it useful to read about how  
Shibboleth must be configured to work with the login page of the  
application to be shibbolized, even if it's a superficial reference to  
a configuration option.
"How it all fits together" step 2 falls short of pointing out how a  
login page may end up being displayed (other than through the natively  
supported LDAP or Kerberos). It does suggest that the IdP may decide  
"how it would like to authenticate the user" but that link could  
indicate customizations.
"Customize user authentication" in the Configuration page also looked  
promising, but it really shows content pertaining to standard  
configuration. Customization is a misnomer, but I had to read the  
whole article to realize that.

I'm afraid our conversation is moving away from its intended course,  
so I'd not put much time into the wiki's weaknesses.


>
>
>> What URL the Shibboleth SP publishes its metadata as.
>
> An SP normally does not host its own metadata. It can generate  
> metadata as a
> help for federation enrollment or testing, but it is not advisable to
> directly consume that in real-time or at the URL it happens to come  
> from.
> The generation process is at /Shibboleth.sso/Metadata but if an SP  
> were to
> hosts its metadata, the location at which it should do so is its  
> entityID.
>

I see. Thanks.

>> I still think the walkthrough would be an important addition. And  
>> once
>> I get to the bottom of this, I may write a quick one myself and push
>> it into the mailing list.
>
> Documentation is welcome, but in the wiki, not the list.
>

Will do.

> -- Scott
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Integrating IdP with Database or File Store

Brent Putman
In reply to this post by Mihai Danila


Mihai Danila wrote:


Others have already replied with most of this, but to summarize and
re-emphasize:


>
> Yes, I am trying to set up IdP as part of my testing here. I'm
> thinking that, at the very least, Shibboleth IdP will present the user
> with a webpage produced by whatever authentication module it delegates
> authentication to. (That web page would post back to the IdP, or at
> least that's what the SAML diagrams I've seen around suggest.)


It may do this, or it may not.  How Shib will do authentication is
determined by the LoginHandler that runs for a given request (in turn
selected based on the effective SAML AuthenticationMethod that is chosen
by the IdP, see link below).  It may or may not be username-password
oriented.  If it is: it may or may not use a web page to collect the
username and password for the user.  Examples of LoginHandler impls that
we supply are here:

https://spaces.internet2.edu/display/SHIB2/IdPUserAuthn



> Or does Shibboleth present its own webpage with a username field and a
> credential field and then obliviously plugs these into the module? How
> that webpage comes about is part of that missing information. I'll do
> some more reading.



The LoginHandler that we ship that does what you describe, and where
credential validation is handled by the IdP directly, is the
UsernamePassword one:

https://spaces.internet2.edu/display/SHIB2/IdPAuthUserPass

It collects the username and password with a web form, and validates it
with a JAAS module.   For more info see the docs for that LoginHandler.
We supply in the Shib distribution a JAAS module for LDAP and JRE's
typically supply one for Kerberos.  You can "easily" (if you're familiar
with JAAS) supply and configure a JAAS module that uses different
validation logic (e.g. RDBMS, flat file, etc).

If instead you want username/password authentication to be handled
external to the IdP, then the LoginHandler that we supply that is useful
there is the RemoteUser one.  You are responsible for configuring your
web server or Java container appropriately for whatever mechanism you want.

If your needs are more complex than can be handled by locating or
writing a different JAAS module, or using the RemoteUser handler, then
you probably have to look at writing your own Login Handler.  (Note that
most people would not really need to consider this..).

--Brent



Reply | Threaded
Open this post in threaded view
|

Re: Integrating IdP with Database or File Store

Mihai Danila

Hi Brent,

Thank you. Your response (along with Paul Hethmon's private replies)  
has cleared it up for me. So now I can use RemoteUser configured with  
a URL that points to a JEE container (which, for my testing purposes,  
could be the Tomcat container that I've installed IdP into), URL that  
I can now protect with standard J2EE mechanisms and even with Tomcat's  
tomcat-users.xml file, both of which I'm very familiar with. This  
arrangement can easily work with legacy authentication mechanisms with  
minimal intervention. One crucial piece of information that I was  
missing before is that there's no standard user+password login page  
provided by Shibboleth for all my needs; I'll have to write my own  
form and throw it in the WAR if I want one (unless I go the JAAS  
provider route).

Thanks again.


Mihai


On Jan 21, 2009, at 5:13 PM, Brent Putman wrote:

>
>
> Mihai Danila wrote:
>
>
> Others have already replied with most of this, but to summarize and
> re-emphasize:
>
>
>>
>> Yes, I am trying to set up IdP as part of my testing here. I'm
>> thinking that, at the very least, Shibboleth IdP will present the  
>> user
>> with a webpage produced by whatever authentication module it  
>> delegates
>> authentication to. (That web page would post back to the IdP, or at
>> least that's what the SAML diagrams I've seen around suggest.)
>
>
> It may do this, or it may not.  How Shib will do authentication is
> determined by the LoginHandler that runs for a given request (in turn
> selected based on the effective SAML AuthenticationMethod that is  
> chosen
> by the IdP, see link below).  It may or may not be username-password
> oriented.  If it is: it may or may not use a web page to collect the
> username and password for the user.  Examples of LoginHandler impls  
> that
> we supply are here:
>
> https://spaces.internet2.edu/display/SHIB2/IdPUserAuthn
>
>
>
>> Or does Shibboleth present its own webpage with a username field  
>> and a
>> credential field and then obliviously plugs these into the module?  
>> How
>> that webpage comes about is part of that missing information. I'll do
>> some more reading.
>
>
>
> The LoginHandler that we ship that does what you describe, and where
> credential validation is handled by the IdP directly, is the
> UsernamePassword one:
>
> https://spaces.internet2.edu/display/SHIB2/IdPAuthUserPass
>
> It collects the username and password with a web form, and validates  
> it
> with a JAAS module.   For more info see the docs for that  
> LoginHandler.
> We supply in the Shib distribution a JAAS module for LDAP and JRE's
> typically supply one for Kerberos.  You can "easily" (if you're  
> familiar
> with JAAS) supply and configure a JAAS module that uses different
> validation logic (e.g. RDBMS, flat file, etc).
>
> If instead you want username/password authentication to be handled
> external to the IdP, then the LoginHandler that we supply that is  
> useful
> there is the RemoteUser one.  You are responsible for configuring your
> web server or Java container appropriately for whatever mechanism  
> you want.
>
> If your needs are more complex than can be handled by locating or
> writing a different JAAS module, or using the RemoteUser handler, then
> you probably have to look at writing your own Login Handler.  (Note  
> that
> most people would not really need to consider this..).
>
> --Brent
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Integrating IdP with Database or File Store

Brent Putman


Mihai Danila wrote:
>
> Hi Brent,
>
> Thank you. Your response (along with Paul Hethmon's private replies)
> has cleared it up for me. So now I can use RemoteUser configured with
> a URL that points to a JEE container (which, for my testing purposes,
> could be the Tomcat container that I've installed IdP into), URL that
> I can now protect with standard J2EE mechanisms and even with Tomcat's
> tomcat-users.xml file, both of which I'm very familiar with.

Yes.  If you do the authentication in your IdP's Java container, the
endpoint that you would protect by default with J2EE declarative
container managed security is /<CONTEXT_PATH>/Authn/RemoteUser, as
documented in the RemoteUser handler page.

You will find an example of this config commented out in the IdP's
web.xml.


> This arrangement can easily work with legacy authentication mechanisms
> with minimal intervention. One crucial piece of information that I was
> missing before is that there's no standard user+password login page
> provided by Shibboleth for all my needs; I'll have to write my own
> form and throw it in the WAR if I want one (unless I go the JAAS
> provider route).

Actually, I believe there is.  If you want to do a servlet API
auth-method of FORM, I believe you can just use the login.jsp that is
included in the war file.  It is written in such a way that it can be
used for either the UsernamePassword LoginHandler, or as the
form-login-page for J2EE container managed security.

Of course, if you want to customize the look and feel of that, you can.

--Brent


Reply | Threaded
Open this post in threaded view
|

RE: Integrating IdP with Database or File Store

Cantor, Scott E.
In reply to this post by Mihai Danila
Mihai Danila wrote on 2009-01-21:
>  In order to shibbolize an application, both use cases (request
> authentication and process an assertion, or something that comes into
> the application from the SP as a result of an assertion) must be taken
> into account. My feeling is that both should be presented in the article.

Sorry, but I don't really understand what you're talking about.

>  I understand that the basic web browser profile can be used to
> successfully authenticate users and the SP and IdP don't have to
> communicate.

That has nothing to do with whether attributes are involved or not.
Attributes and attribute queries are not necessarily connected. You said
nothing about queries, you specifically wanted to avoid attributes
altogether.

> In "Shibbolizing an application." I find it useful to read about how
> Shibboleth must be configured to work with the login page of the
> application to be shibbolized, even if it's a superficial reference to
> a configuration option.

That is a system and application design issue that goes a long way beyond
Shibboleth. And there is no such "option" to reference. It's much more
complicated and application-dependent.

-- Scott



Reply | Threaded
Open this post in threaded view
|

Re: Integrating IdP with Database or File Store

Mihai Danila

Hi Scott,

So you're basically saying that it's good that no reference to this out of scope information is made in the wiki, because the user can and should find out about it somewhere else. Since where we define the boundaries of the info that goes into each wiki page is subject to personal biases, we could keep talking about it for ages without reaching consensus. My general feeling still is that a walkthrough will add a lot of value, as the wiki as it stands fails to put certain info in context.

BTW, I'd add this info to the troubleshooting guide:
If the login phase hangs when trying to access a protected resource, check that you enabled SSL within the IdP's container, or open the IdP metadata and change the Location of the SingleSignonService elements to use HTTP instead of SSL.

Also see some notes inline.

On Jan 22, 2009, at 10:57 AM, Scott Cantor wrote:

Mihai Danila wrote on 2009-01-21:
In order to shibbolize an application, both use cases (request
authentication and process an assertion, or something that comes into
the application from the SP as a result of an assertion) must be taken
into account. My feeling is that both should be presented in the article.

Sorry, but I don't really understand what you're talking about.

I'll go back to my original complaing about the "Shibbolize an application" wiki page: 
"Shibbolizing an application" was another of my reads; but while it
features links to scripts that a Shib-aware application may use, it
doesn't say what configuration option in the IdP must be actuated in
order to make the link to the application.

And your answer:
Because there isn't one in general. The SP is responsible for making the
authentication requests. The IdP configuration controls what happens when it
gets one.

Now, "shibbolize" can be overloaded with meaning; I, for one, was hoping to read (among other things) about how legacy login systems might be integrated with Shibboleth. In this context, I assumed that the IdP, which is, according to the protocol, responsible for the authentication, will, either directly or through the SP, need to access the login service of the legacy application. I realize this is not a general use case, but it's one that people will ask about. I had a hard time figuring out how that might happen: a RemoteUser login handler configured with a copy of the legacy system's login form that resides in the container, copy that posts back to an IdP servlet, servlet which then accesses the legacy application and sets the relevant headers, may do the trick from the IdP's perspective.



I understand that the basic web browser profile can be used to
successfully authenticate users and the SP and IdP don't have to
communicate.

That has nothing to do with whether attributes are involved or not.
Attributes and attribute queries are not necessarily connected. You said
nothing about queries, you specifically wanted to avoid attributes
altogether.

I didn't want to lay out why I might want an attribute-free arrangement, because it tends to elicit the well known exchange of messages "I want to do this;" "But why don't you do this instead," etc. All I care is that their optionality shouldn't cause me to have to dig into the attribute configuration files for my basic setup (excerpt: "I hope it [the relevant configuration option] is not going to be found in any Attributes-related article, as I assumed attributes are optional I can safely skip those for the purposes of basic setup.").



In "Shibbolizing an application." I find it useful to read about how
Shibboleth must be configured to work with the login page of the
application to be shibbolized, even if it's a superficial reference to
a configuration option.

That is a system and application design issue that goes a long way beyond
Shibboleth. And there is no such "option" to reference. It's much more
complicated and application-dependent.

If your feeling is that it's not something to write about in more detail, then don't. You don't really need my acceptance.



-- Scott





Mihai

Reply | Threaded
Open this post in threaded view
|

Re: Integrating IdP with Database or File Store

Mihai Danila

These small objections about the Wiki aside, I must add that a lot of useful information has come on the list. I'm glad you warned me that attributes should be used in implementing a SAML-based authentication scheme and you've also provided useful information in other respects (legacy systems not preferred, out of scope information that helped me put things in context, etc.).

Mihai


On Jan 22, 2009, at 11:50 AM, Mihai Danila wrote:


Hi Scott,

So you're basically saying that it's good that no reference to this out of scope information is made in the wiki, because the user can and should find out about it somewhere else. Since where we define the boundaries of the info that goes into each wiki page is subject to personal biases, we could keep talking about it for ages without reaching consensus. My general feeling still is that a walkthrough will add a lot of value, as the wiki as it stands fails to put certain info in context.

BTW, I'd add this info to the troubleshooting guide:
If the login phase hangs when trying to access a protected resource, check that you enabled SSL within the IdP's container, or open the IdP metadata and change the Location of the SingleSignonService elements to use HTTP instead of SSL.

Also see some notes inline.

On Jan 22, 2009, at 10:57 AM, Scott Cantor wrote:

Mihai Danila wrote on 2009-01-21:
In order to shibbolize an application, both use cases (request
authentication and process an assertion, or something that comes into
the application from the SP as a result of an assertion) must be taken
into account. My feeling is that both should be presented in the article.

Sorry, but I don't really understand what you're talking about.

I'll go back to my original complaing about the "Shibbolize an application" wiki page: 
"Shibbolizing an application" was another of my reads; but while it
features links to scripts that a Shib-aware application may use, it
doesn't say what configuration option in the IdP must be actuated in
order to make the link to the application.

And your answer:
Because there isn't one in general. The SP is responsible for making the
authentication requests. The IdP configuration controls what happens when it
gets one.

Now, "shibbolize" can be overloaded with meaning; I, for one, was hoping to read (among other things) about how legacy login systems might be integrated with Shibboleth. In this context, I assumed that the IdP, which is, according to the protocol, responsible for the authentication, will, either directly or through the SP, need to access the login service of the legacy application. I realize this is not a general use case, but it's one that people will ask about. I had a hard time figuring out how that might happen: a RemoteUser login handler configured with a copy of the legacy system's login form that resides in the container, copy that posts back to an IdP servlet, servlet which then accesses the legacy application and sets the relevant headers, may do the trick from the IdP's perspective.



I understand that the basic web browser profile can be used to
successfully authenticate users and the SP and IdP don't have to
communicate.

That has nothing to do with whether attributes are involved or not.
Attributes and attribute queries are not necessarily connected. You said
nothing about queries, you specifically wanted to avoid attributes
altogether.

I didn't want to lay out why I might want an attribute-free arrangement, because it tends to elicit the well known exchange of messages "I want to do this;" "But why don't you do this instead," etc. All I care is that their optionality shouldn't cause me to have to dig into the attribute configuration files for my basic setup (excerpt: "I hope it [the relevant configuration option] is not going to be found in any Attributes-related article, as I assumed attributes are optional I can safely skip those for the purposes of basic setup.").



In "Shibbolizing an application." I find it useful to read about how
Shibboleth must be configured to work with the login page of the
application to be shibbolized, even if it's a superficial reference to
a configuration option.

That is a system and application design issue that goes a long way beyond
Shibboleth. And there is no such "option" to reference. It's much more
complicated and application-dependent.

If your feeling is that it's not something to write about in more detail, then don't. You don't really need my acceptance.



-- Scott





Mihai


Reply | Threaded
Open this post in threaded view
|

RE: Integrating IdP with Database or File Store

Cantor, Scott E.
In reply to this post by Mihai Danila
Mihai Danila wrote on 2009-01-22:
> So you're basically saying that it's good that no reference to this out of
> scope information is made in the wiki, because the user can and should
find
> out about it somewhere else.

Yeah, pretty much, though I tend to believe, based on the complete
brokenness of most of the applications in the world, that such material
probably can't be found easily. That doesn't make it easy to create it.
 
> My general
> feeling still is that a walkthrough will add a lot of value, as the wiki
as
> it stands fails to put certain info in context.

Then by all means do so.
 
> BTW, I'd add this info to the troubleshooting guide:

See previous sentence.
 
> Now, "shibbolize" can be overloaded with meaning; I, for one, was hoping
to
> read (among other things) about how legacy login systems might be
integrated
> with Shibboleth. In this context, I assumed that the IdP, which is,
> according to the protocol, responsible for the authentication, will,
either
> directly or through the SP, need to access the login service of the legacy
> application.

It cannot do so through the SP. The best advice I would have is to get the
legacy service out of the application and put it behind the IdP as a
back-end.
 
> I realize this is not a general use case, but it's one that
> people will ask about. I had a hard time figuring out how that might
happen:
> a RemoteUser login handler configured with a copy of the legacy system's
> login form that resides in the container, copy that posts back to an IdP
> servlet, servlet which then accesses the legacy application and sets the
> relevant headers, may do the trick from the IdP's perspective.

That's the technical detail of doing what I suggested above. Most of that is
about IdP authentication configuration. Clearly you didn't get what you
needed from the documentation that was already there about those topics, but
that doesn't mean the attempt wasn't made.
 
> All I care is that their
> optionality shouldn't cause me to have to dig into the attribute
> configuration files for my basic setup (excerpt: "I hope it [the relevant
> configuration option] is not going to be found in any Attributes-related
> article, as I assumed attributes are optional I can safely skip those for
> the purposes of basic setup.").

If you don't do anything, what you'll get at the SP is a transient ID that
will change every time you login, and will not appear in a header. All the
application will get from the SP will be a few default variables identifying
the IdP, authn method/time, etc. If that's enough for you, that's fine, but
it certainly won't help you in a real application.

Changing that (without relying on attributes at all) is possible, but cannot
be done in either the SP or IdP without altering the attribute configuration
material in relatively confusing (to a novice) ways. If you doubt me, search
for the threads on google apps.

-- Scott


Reply | Threaded
Open this post in threaded view
|

Re: Integrating IdP with Database or File Store

Tom Scavo
In reply to this post by Mihai Danila
On Thu, Jan 22, 2009 at 11:50 AM, Mihai Danila <[hidden email]> wrote:
>
> Now, "shibbolize" can be overloaded with meaning; I, for one, was hoping to
> read (among other things) about how legacy login systems might be integrated
> with Shibboleth.

This is accomplished by deploying an IdP alongside the SP.  Now the
local IdP becomes but one authentication source among many.  The
discovery service is modified to include the local IdP in the
discovery process.

If your application currently manages its own credentials
(username/password, e.g.), this is a necessary first step to free it
from the burden of credential management.

Hope this helps,
Tom
Reply | Threaded
Open this post in threaded view
|

RE: Integrating IdP with Database or File Store

Cantor, Scott E.
In reply to this post by Mihai Danila
Mihai Danila wrote on 2009-01-22:
> I'm glad you warned me that
> attributes should be used in implementing a SAML-based authentication
> scheme

I'm not necessarily saying that at all, I'm saying Shibboleth does not make
it trivial out of the box to get to a NameID-only SAML configuration, and
the changes to allow that involve the same files you're trying to avoid
changing.

This is because of historical bias and the use cases most people have.

-- Scott


12