Setting up a SAML 2.0 SP chain to an IdP?

[Douglas Teoh]

I'm wondering if it is possible to achieve this sort of setup:

IdP <---> Shared SP (reachable from the IdP host) <---> Local/Application SP (not reachable from IdP host, not reachable from Shared SP host)

I got the idea for this setup from a diagram on OneLogin's website about "SAML chaining". 

What I am unsure of is that I was told that an IdP must be able to query an SP. Since I don't want to run an IdP on our dev machines, I thought that having a shared SP that the IdP can access could solve this problem. My hope is that, a locally running application can just use the shared SP to proxy authentication requests.

I haven't really been able to find much information about this type of setup. I'm new to SAML 2.0 so I am possibly not using the right terminology to describe the setup.

[Tom Scavo]

On Tue, Jun 25, 2013 at 9:48 PM, Douglas Teoh <dou...@dteoh.com> wrote:
> I'm wondering if it is possible to achieve this sort of setup:
>
> IdP <---> Shared SP (reachable from the IdP host) <---> Local/Application SP
> (not reachable from IdP host, not reachable from Shared SP host)
>
> I got the idea for this setup from a diagram on OneLogin's website about
> "SAML chaining".
>

> I haven't really been able to find much information about this type of
> setup. I'm new to SAML 2.0 so I am possibly not using the right terminology
> to describe the setup.

The thing you're calling a "shared SP" is called an "IdP Proxy" in the
original OASIS SAML specification. By definition, a SAML IdP Proxy is
a SAML-to-SAML gateway that sits between an IdP and an SP (as shown in
your diagram). Clearly an IdP Proxy must have an SP component (so it
can talk to the IdP) but it must also have an IdP component (so it can
talk to the SP).

That should give you enough to google :-)

Tom

[Peter Schober]

* Douglas Teoh <dou...@dteoh.com> [2013-06-26 07:20]:

> What I am unsure of is that I was told that an IdP must be able to
> query an SP.

Not in the way "query" is used within SAML, no. There are cases where
the SP needs to query the IdP for data (i.e., the other way around)
but you can chose not to support those SAML interactions, which makes
deployment much easier.
Then the only connections that need to work are HTTP User Agent to
both IdP and SP, wherever they sit,
-peter

[Douglas Teoh]

On Wednesday, June 26, 2013 10:38:35 PM UTC+10, Peter Schober wrote:

* Douglas Teoh <dou...@dteoh.com> [2013-06-26 07:20]:
> What I am unsure of is that I was told that an IdP must be able to
> query an SP.

Not in the way "query" is used within SAML, no. There are cases where
the SP needs to query the IdP for data (i.e., the other way around)
but you can chose not to support those SAML interactions, which makes
deployment much easier.

From what I read, the IdP needs to ping the SP to get/refresh metadata, no?

What about for AssertionConsumerService described in the docs? (http://simplesamlphp.org/docs/trunk/simplesamlphp-reference-sp-remote)

Is this just for the IdP to redirect the user's browser back to the SP?

Thanks,

Douglas

[Douglas Teoh]

Thanks, I have started creating an SSP installation which acts as both. The

configuration between the remote IdP + proxy was straightforward enough.

I'm still unsure about the configuration between the proxy and my local app.

My understanding is that I will still need to create a metadata entry inside

saml20-sp-remote.php for each app. I was hoping that this isn't needed,

that my local app will just pass its metadata along on the initial request.

Douglas

[Peter Schober]

* Douglas Teoh <dou...@dteoh.com> [2013-06-27 07:23]:

> > Not in the way "query" is used within SAML, no. There are cases where
> > the SP needs to query the IdP for data (i.e., the other way around)
> > but you can chose not to support those SAML interactions, which makes
> > deployment much easier.

> From what I read, the IdP needs to ping the SP to get/refresh
> metadata, no?

Asking the very party you want to interact with to self-assert
security information (such as protocol end points and cryprographic
keys) does not give you any assurance or security of the fidelity of
that data.
But the answer depends on your trust model. In large multi-lateral
identity federations you have a trusted third party that vouches for
the metadata and signs it with a trusted key (how trust in that key is
bootstrapped is a different matter, let's say it happens OOB). Members
of the club then regularly pull metadata from the 3rd party, verifying
the cryptographic signature on the metadata itself.

Anyway, refreshing metadata has nothing to do with the procotocl
exchanges involved in a SAML interaction. You can keep the latter as
simple as I stated above.

> What about for AssertionConsumerService described in the docs?
> (http://simplesamlphp.org/docs/trunk/simplesamlphp-reference-sp-remote)
> Is this just for the IdP to redirect the user's browser back to the SP?

Well, what about it? If you want to know more about that have a look
at the SAML specification.
Like I said, there are protocol bindings that involve the SP pulling
data directly from the IDP, mostly to prevent data passing though the
HTTP User Agent in the clear. And you don't need to support those.
Using SAML2 with encrypted SAML assertions gives you the same
protection without requring back-channel communicatons between the SP
and the IDP.
-peter

[Tom Scavo]

On Thu, Jun 27, 2013 at 1:29 AM, Douglas Teoh <dou...@dteoh.com> wrote:
>
> Thanks, I have started creating an SSP installation which acts as both.

Yes, SSP handles the "IdP Proxy" use case very well.

> The
> configuration between the remote IdP + proxy was straightforward enough.

Good.

> I'm still unsure about the configuration between the proxy and my local app.

To your local app, the IdP Proxy appears as an ordinary IdP, so
configure your app accordingly.

> My understanding is that I will still need to create a metadata entry inside
> saml20-sp-remote.php for each app. I was hoping that this isn't needed,
> that my local app will just pass its metadata along on the initial request.

This is a general question that has nothing to do with the IdP Proxy.

See Peter's remarks re metadata and federations, but the short answer
is no, metadata is not shared upon first use. There's no security in
that.

Tom

[Shirlei Chaves]

Hello you all!

Currently I'm working at implementing the SAMLIdPProxy cited in this thread and specified at https://spaces.internet2.edu/display/GS/SAMLIdPProxy

I have installed simplesamlphp at a host and as far as I can see, have configured both saml idp and saml sp at that host. The SP is able to connect to the shib idp federation as shown in the attached figure.

As I'm trying to do things step-by-step, now I'm working on connecting my shibboleth sp (from the ' Federation SP') to my simplesamlphp idP. In this step I'm having some issues probably due to misconfigurations, as I stated in here: https://groups.google.com/forum/#!topic/simplesamlphp/nHGJ98dnxFA

After I solve that, I intend to work on the proxy itself... 

My question: is that the right approach?

And two another ones, even more newbie:
 Do I configure my shib SPs, in the SSP IdP shib13-sp-remote.php file? Could you possibly share an example?  Or tell me if just this is ok:

$metadata['https://<host>/shibboleth-sp2'] = array(

        'AssertionConsumerService' => 'https://<host>/Shibboleth.sso/SAML/POST',
        'base64attributes'         => FALSE,
);

where 'https://<host>/shibboleth-sp2' is my entityId at shibboleth2.xml.

Also, is this correct (at shibboleth2.xml) :

      <SSO entityID="https://<host>

simplesaml/saml2/sp/idpdisco.php">SAML2</SSO>

<MetadataProvider type="XML" uri="https://<host>/

simplesaml/saml2/idp/metadata.php?output=xml" backingFilePath="ds-metadata.xml" reloadInterval="7200">

I really appreciate any help.
Thank you very much!!

[Shirlei Chaves]

Oops, missed the attachment

[Mathias Meisfjordskar]

Hello.

We (the University of Oslo) are currently developing a module that does something similar to this. The goal is to enable seamless IdP proxying for SPs at a local IdP. The picture will look something like this:

SP -> IdP1 -> IdP2

The user selects the remote IdP (IdP2) from a list of tabs at the login screen (that support various backends and remote IdPs as tabs). The goal with this module is to allow barebone config and setup on SPs and handle the proxying centrally at the IdP (IdP1). All SPs wanting to support one or more remote IdPs means the admins of the local IdP setting up handles with remote IdPs as if they represented the SP. This means attribute release and other remote IdP SP config is respected.

We currently support something like this, but with links on the local IdP to a secondary SP in the web service the login request originated from. This is an ad hoc solution that few are able to implement and makes session handling quite messy in the web app. Our current login page looks like this:

http://www.uio.no/tjenester/it/brukernavn-passord/weblogin/weblogin-bilder/weblogin-vindu.png

The new module will look something like the above. We are not aiming to support big WAYF splash pages once we release this, but that should be trivial to support later on. There are numerous other features and support for my other module 'Negotiate' built into this (via a new hook, naturally). I'll give a better presentation once we release this for review here on this list.

The module also includes a patch Olav made some time ago to allow such proxying inside SSP. We are aiming for an initial release after New Year. 

Regards,

Mathias Meisfjordskar

University of Oslo

--
You received this message because you are subscribed to the Google Groups "simpleSAMLphp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to simplesamlph...@googlegroups.com.
To post to this group, send email to simple...@googlegroups.com.
Visit this group at http://groups.google.com/group/simplesamlphp.
For more options, visit https://groups.google.com/d/optout.

[Shirlei Chaves]

Thank you Mathias! Looking forward to hear from the presentation once you released it.