IdP Proxy which is SP at the same time

[magnus...@gmail.com]

I would like to know if the following scenario is possible to implement with Simplesamlphp.

Right now I have the following working setup:

B (SP) <-------------> C (IdP with login page)

I'd like to introduce another machine A, which is a SP and should use B as an IdP which internally should use C as IdP which leads to the following:

A (SP) <-------> B (IdP) <-----------------> C (IdP)

So B has two functions:
1. Act as SP which uses C as IdP (like it does now)
2. Act as IdP for A but internally use C and deliver login page of C.

I'm new to SimpleSamlPHP, is this possible/difficult to implement?

Is a good way of trying this scenario to define 3 vhosts in my apache config?

Thanks 

[Peter Schober]

* magnus...@gmail.com <magnus...@gmail.com> [2015-10-16 16:59]:

> I would like to know if the following scenario is possible to
> implement with Simplesamlphp.

It is, and some people on this list have plenty of experience with
running SSP in such a way (myself not included).
-peter

[Michael Dondrup]

Hi,

we are testing a similar setup. Note that in case you connect more
SP's to IdP C, single logout will not be propagated 'downwards'
from them to A. That means that A might stay logged in after a
single logout at C until it tries to refreshesh its session.

Best

Michael Dondrup
Researcher
Sea Lice Research Centre
Department of Informatics
University of Bergen
Thormøhlensgate 55, N-5008 Bergen,
Norway

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

[Tom Ggroups]

Hi,

just wanted to let you know that I successfully implemented that setup. On my virtual machine I created 3 different vhosts for each of the machines with different host names. I then followed the installation instructions for SP and IdP to configure each of the machines:

1. I started with the configuration of B as an SP.

2. To add the IdP to B I followed the instructions to configure C as IdP using exampleauth.

3. I exchanged the metadata between them and successfully tested the setup.

4. I enabled IdP on B. In authsources.php I didn't have to change anything, because the remote IdP was already configured in step 1 and 2.

5. After the configuration of A as SP I exchanged metadata between A and B.

Everything works as expected. Not as difficult as I thought in the beginning.

Michael, I was also able to test the logout propagation issue. When I single logout from A, B is also logged out as the information passes through B when logging out at C. But if I log out at B, A of course is still logged in until the session expires.

Thanks for pointing that out.

Regards

Tom

[Shweta]

Tom,

New to SSP.

I am trying to setup/try something similar but with Shibboleth on A and C  while B is going to be some custom pages using SSP libraries to act like an IdP for A (receive request, and send response) 

Basically, after C authenticates and comes back to B, I have the attributes available that need to be sent to A. 

At this point I need to generate an appropriate SAMLResponse for A,  using attributes received from C. 

I have been able to dig up enough to know I would need SAML2_Response and use a SAML2_HTTPPost to help me with that. I also need to add an Assertion to the response for all those attributes. 

Is this the right approach?It is missing the whole step of setting attributes, which is what I am trying to figure out!

 $response_message = new SAML2_Response();

$response_message->setId($response_id);

$response_message->setDestination($response_destination);

$response_message->setIssuer($response_issuer);

$response_message->setRelayState($response_relayState);

$response_message->setSignatureKey($response_signatureKey);


$binding = new SAML2_HTTPPost($response_message);
$response = $binding->send($response_message);

       

Any guidance on where in the code can I look and copy/paste in my custom pages to implement this response. 

Thanks, 

Shweta

[Peter Schober]

* Shweta <shweta...@gmail.com> [2015-11-17 21:52]:

> I am trying to setup/try something similar but with Shibboleth on A and C
> while B is going to be some custom pages using SSP libraries to act like
> an IdP for A (receive request, and send response)
>
> Basically, after C authenticates and comes back to B, I have the attributes
> available that need to be sent to A.
> At this point I need to generate an appropriate SAMLResponse for A, using
> attributes received from C.

Unless you insist on not using SimpleSAMLphp (in which case this is
the wrong list, maybe try the -dev list for help with custom code
using parts of SSP) that sounds like it would be done with simply
configuring SSP as both an IDP and SP and exchanging metadata with the
SP and IDP, respectively. No coding involved.
-peter

[Shweta]

Peter,

I will post on the -dev list for custom code just to get the Proof of Concept working.

However, what I am really trying to do here is a Hub and Spoke model where all the SPs (multiple As) only know of 1 IdP (B in the example) and B does the job of presenting a list of institutions and then sending auth request to the user selected institution's IdP (Cs). B then generates its own SAMLResponse for the SPs based on results from the IdP. 

• Has anyone here successfully done this?
• In your suggestion of setting up SSP as both IdP and SP, I don't understand how that would work in this case. If it still would please could you elaborate..

[Scotty Logan]

On Wed, Nov 18, 2015 at 7:52 AM, Shweta <shweta...@gmail.com> wrote:

However, what I am really trying to do here is a Hub and Spoke model where all the SPs (multiple As) only know of 1 IdP (B in the example) and B does the job of presenting a list of institutions and then sending auth request to the user selected institution's IdP (Cs). B then generates its own SAMLResponse for the SPs based on results from the IdP. 

• Has anyone here successfully done this?

We’ve done something similar; we’re using an SSP proxy (with the PDO metadata patch on the IdP side of the proxy) to support SPs that are spun up (and torn down) quickly, while avoiding the need to constantly update / download / reload a metadata file.  The backend IdP is a Shibboleth 2.x IdP.  We’ve also done some testing with Facebook and a Shibboleth IdP behind an SSP proxy.

• In your suggestion of setting up SSP as both IdP and SP, I don't understand how that would work in this case. If it still would please could you elaborate..

SSP can act as an IdP and an SP at the same time; you would configure the SP side to authenticate to the federation IdPs, and configure the IdP side to use the SP for authentication.  This is the magic entry in saml20-idp-hosted.php:

  $metadata[$idp_entity_id] = array(

    …

    'auth' => 'default-sp’,

    …

  );

You can probably do the same thing with Shibboleth, but it requires more effort.

WARNING:  If you just pass through attributes from the federation IdPs, you’ll need to add all the federation IdP domains to the scope array in the IdP metadata; this also means your IdP will be lying to all the SPs, since it’s claiming to be authoritative for all those domains when it’s really not.

WARNING#2: This also implies that all the SPs have the same relationship with all the federation IdPs, which may not be true.  Your proxy has no way to know which IdPs are trusted by which SPs.

QUESTION: why are you trying to do this, rather than allowing the SPs to communicate with the federation IdPs directly?

We’re using our current proxy for a very limited use case, where speed of deployment of new SPs is important, and is fully under our control.  The only other use case we’re considering is to make it easier for our internal federation to deal with brain-dead SPs that can only handle a single IdP;  however, since there are less than a handful of IdPs, we can (and would) get approval from the owners of the domains / IdPs before setting up a proxy that claimed to be authoritative for them.

TL;DR: it’s doable, but make sure you’re doing it for the right reasons.

  Scotty

[Shweta]

Scotty,

Thanks for the reply.. this definitely helps in that it makes me hopeful! I have new to SSP and SAML digging around is also new for this PoC, so please excuse obvious questions..  

On Wednesday, November 18, 2015 at 1:47:28 PM UTC-5, Scotty Logan wrote:

On Wed, Nov 18, 2015 at 7:52 AM, Shweta <shweta...@gmail.com> wrote:

However, what I am really trying to do here is a Hub and Spoke model where all the SPs (multiple As) only know of 1 IdP (B in the example) and B does the job of presenting a list of institutions and then sending auth request to the user selected institution's IdP (Cs). B then generates its own SAMLResponse for the SPs based on results from the IdP. 

• Has anyone here successfully done this?

We’ve done something similar; we’re using an SSP proxy (with the PDO metadata patch on the IdP side of the proxy) to support SPs that are spun up (and torn down) quickly, while avoiding the need to constantly update / download / reload a metadata file.  The backend IdP is a Shibboleth 2.x IdP.  We’ve also done some testing with Facebook and a Shibboleth IdP behind an SSP proxy.

I guess the PDO metadata patch unique to your use case. The backend Shib IDP means, that the requesting SP comes to the SSP proxy, where the saml20-idp-remote.php is configured to send to Shib IDP? Can you briefly explain the flow and how configs are setup here?

• In your suggestion of setting up SSP as both IdP and SP, I don't understand how that would work in this case. If it still would please could you elaborate..

SSP can act as an IdP and an SP at the same time; you would configure the SP side to authenticate to the federation IdPs, and configure the IdP side to use the SP for authentication.  This is the magic entry in saml20-idp-hosted.php:

  $metadata[$idp_entity_id] = array(

    …

    'auth' => 'default-sp’,

    …

  );

You can probably do the same thing with Shibboleth, but it requires more effort.

WARNING:  If you just pass through attributes from the federation IdPs, you’ll need to add all the federation IdP domains to the scope array in the IdP metadata; this also means your IdP will be lying to all the SPs, since it’s claiming to be authoritative for all those domains when it’s really not.

Can you please elaborate on adding all federated IdP domains to the scope array? specifically is this a config.php, saml20-idp-remote/hosted.php thing? We have the metadata for all the campuses we are planning to put Proxy in front of, in an xml (Shib format). Extracting from that was the plan, however I have also seen some posts for metadata_converter.php as part of SSP that can help with that ( still to explore). 

 

WARNING#2: This also implies that all the SPs have the same relationship with all the federation IdPs, which may not be true.  Your proxy has no way to know which IdPs are trusted by which SPs.

QUESTION: why are you trying to do this, rather than allowing the SPs to communicate with the federation IdPs directly?

Typically that's how it is done, but some SPs are incapable or don't want to go through the setup of over 15 institutions individual setup. 

 

We’re using our current proxy for a very limited use case, where speed of deployment of new SPs is important, and is fully under our control.  The only other use case we’re considering is to make it easier for our internal federation to deal with brain-dead SPs that can only handle a single IdP;  however, since there are less than a handful of IdPs, we can (and would) get approval from the owners of the domains / IdPs before setting up a proxy that claimed to be authoritative for them.

Your second consideration is exactly why we have to do this. Cloud based SPs and more lacking than others to handle a federated/ multi-institution SSO for a single instance at the SP. We are also going to have only a handful of these. 

[Jaime Perez Crespo]

Hi Shweta,

> On 18 Nov 2015, at 21:39 PM, Shweta <shweta...@gmail.com> wrote:
> However, what I am really trying to do here is a Hub and Spoke model where all the SPs (multiple As) only know of 1 IdP (B in the example) and B does the job of presenting a list of institutions and then sending auth request to the user selected institution's IdP (Cs). B then generates its own SAMLResponse for the SPs based on results from the IdP.

That’s one of the two typical federation models: full mesh and hub & spoke. Nothing fancy here.

> • Has anyone here successfully done this?

The SIR federation in Spain is doing it. WAYF in Denmark is doing it. SURFnet in the Netherlands is doing it. The GÉANT Association is also doing it for all their services. We in Feide are doing it in Norway. Nothing new under the sun.

> • In your suggestion of setting up SSP as both IdP and SP, I don't understand how that would work in this case. If it still would please could you elaborate..

You replied to yourself with your diagram. SSP can be both an IdP and an SP. When acting as an IdP, you need to tell SimpleSAMLphp how to authenticate the user. If you configure it to delegate authentication just the exact same way you would if you were an SP, you are building a SAML proxy.

The best part? You don’t need any custom code for that. Just configure SSP properly.

> I guess the PDO metadata patch unique to your use case. The backend Shib IDP means, that the requesting SP comes to the SSP proxy, where the saml20-idp-remote.php is configured to send to Shib IDP? Can you briefly explain the flow and how configs are setup here?

As I just said, configure your SSP as an IdP. Follow the documentation for that. Then, configure your SSP as an SP, delegating authentication to any other IdP in your federation. Follow the documentation again for that. Once you have both in place, it’s as simple as telling your IdP (metadata/saml20-idp-hosted.php) to use the saml:SP authsource you just defined (config/authsources.php) to authenticate the users. SSP will handle the rest for you.

--
Jaime Pérez
UNINETT / Feide
mail: jaime...@uninett.no
xmpp: ja...@jabber.uninett.no

"Two roads diverged in a wood, and I, I took the one less traveled by, and that has made all the difference."
- Robert Frost

[Scotty Logan]

On Wed, Nov 18, 2015 at 12:39 PM, Shweta <shweta...@gmail.com> wrote:
> I guess the PDO metadata patch unique to your use case.

It was a patch we found on this list to use a database for metadata
rather than local files.

> The backend Shib IDP
> means, that the requesting SP comes to the SSP proxy, where the
> saml20-idp-remote.php is configured to send to Shib IDP? Can you briefly
> explain the flow and how configs are setup here?

We have application SPs (a mix of SSP, mod_auth_mellon, omniauth-saml,
passenger-saml, native inside application (Java), and Shibboleth) that
point to the IdP side of our proxy. Our proxy IdP is configured to
advertise (via <md:Extensions><shibmd:Scope>our-domain</></>) that
it’s authoritative for our domain so that the SPs will accept scoped
attributes using our domain from the proxy. It is also configured to
use ‘default-sp' for authentication. On the SP side of our proxy
(‘default-sp’) the SP is registered with our campus IdP (Shibboleth).

We’re using puppet to build docker images, then injecting
configuration via volume mounts and environment variables / files, so
we use environment variable all over our configuration; this enables
us to run the same idpproxy image on different subdomains against dev
and prod IdPs. Additionally, our idpproxy image is just a few files
dropped on top of a base LAMP + SSP image, which already includes the
metadata for all our IdPs and proxies. I’ll explain the environment
variables below:

In authsources.php:

'default-sp' => array(
'saml:SP',
'privatekey' => 'idpproxy.key',
'certificate' => 'idpproxy.pem',
'entityID' => $_SERVER['ENV_ENTITY_ID'],
'idp' => $_SERVER['ENV_IDP'],

'authproc' => array(
20 => 'saml:NameIDAttribute',
),

ENV_ENTITY_ID is the SAML entity ID for the SP side of the proxy
ENV_IDP is the SAML entity ID for the campus IdP.

In config.local.php (included from config.php):

$config['metadata.sources'][] = array(
'type' => 'pdo',
'dsn' => 'mysql:host=' . $_SERVER['RDS_HOSTNAME']
. ';dbname=' . $_SERVER['RDS_DB_NAME'],
'username' => $_SERVER['RDS_USERNAME'],
'password' => $_SERVER['RDS_PASSWORD'],
'tablePrefix' => 'sspmd_'
);

$config["enable.saml20-idp"] = true;

All our applications use the RDS_* variables to access their
databases; the names came from an early setup of other applications on
AWS Elastic Beanstalk.
All our SSP configurations use the same database for session state,
and our idpproxy uses the PDO patch to access metadata from a
database.

In saml20-idp-hosted.php:

$metadata[$_SERVER['ENV_ENTITY_ID'] . 'idp'] = array(
'host' => $_SERVER['ENV_DOMAIN'],

/* X.509 key and certificate. Relative to the cert directory. */
'privatekey' => 'idpproxy.key',
'certificate' => 'idpproxy.pem',

// use the local SP for authentication
'auth' => 'default-sp',

'scope' => array ('our-domain'),

'signature.algorithm' =>
'http://www.w3.org/2001/04/xmldsig-more#rsa-sha256',
'attributes.NameFormat' =>
'urn:oasis:names:tc:SAML:2.0:attrname-format:uri',
'authproc' => array(
1 => array(
'class' => 'saml:TransientNameID',
),
2 => array(
'class' => 'saml:PersistentNameID',
'attribute' => 'eduPersonPrincipalName',
),
3 => array(
'class' => 'saml:AttributeNameID',
'attribute' => 'mail',
'Format' => 'urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress',
),
// Convert LDAP names to oids.
99 => array(
'class' => 'core:AttributeMap',
'name2oid',
'%duplicate',
),
100 => array(
'class' => 'core:AttributeMap',
'mail' => array('mail', 'email'),
'displayName' => array('displayName', 'name'),
),
),
);

ENV_ENTITY_ID is the same as in authsources.php
ENV_DOMAIN is the hostname for the idpproxy

Since our applications using SSP as an SP prefer attribute names to
OIDs, our base LAMP + SSP image maps OIDs to names; authproc 99 maps
those names back to OIDs, while preserving the named attributes (the
‘%duplicate’ option) for SAML SPs behind the proxy that need / prefer
OIDs.

We also have some apps with “interesting” ideas about attribute
naming, so authproc 100 adds extra names for some common attributes.

> Can you please elaborate on adding all federated IdP domains to the scope
> array? specifically is this a config.php, saml20-idp-remote/hosted.php
> thing? We have the metadata for all the campuses we are planning to put
> Proxy in front of, in an xml (Shib format). Extracting from that was the
> plan, however I have also seen some posts for metadata_converter.php as part
> of SSP that can help with that ( still to explore).

InCommon, and presumably some other federations based on it, publish
‘scope’ metadata for IdPs - a list of scopes that each IdP is allowed
to use. The idea is that exampleA.com’s IdP should not be releasing
scoped attributes using exampleB.com, unless exampleB has instructed
the federation that exampleA is allowed to do that. By default
Shibboleth (and SSP, I think) SPs will rejected scoped attributes from
an IdP for scopes not listed in that IdP’s metadata. InCommon
participants use two main scoped attributes - eduPersonPrincipalName
and eduPersonScopedAffiliation - so it’s important for IdPs in
InCommon to list the correct scopes; it may be less necessary in other
federations.

> Your second consideration is exactly why we have to do this. Cloud based SPs
> and more lacking than others to handle a federated/ multi-institution SSO
> for a single instance at the SP. We are also going to have only a handful of
> these.

Sometimes the vendors need more experience with SAML, other times
they’re restricted by the SAML implementation they chose (most
commercial implementations don’t have support for automated metadata
yet, as an example).

Scotty

[Tom Scavo]

Basically, that's correct info (modulo a detail here and there :) but
here's a suggestion how to handle scoped attributes:

As you've noted, scoped attributes don't transit a gateway (or proxy)
very well (by design) so don't do that. Take the ePPN (or email
address) that you get from the IdP and convert it programmatically
into an ePPN for which you (the gateway or proxy) are authoritative.
For example, convert email address trs...@gmail.com into
trscavo+...@mygateway.org. Same for an ePPN. In that way, only
one scope is needed in gateway (or proxy) metadata and your SPs remain
happy campers.

Tom

[Scotty Logan]

On Wed, Nov 18, 2015 at 6:14 PM, Tom Scavo <trs...@gmail.com> wrote:
> Basically, that's correct info (modulo a detail here and there :) but
> here's a suggestion how to handle scoped attributes:
>
> As you've noted, scoped attributes don't transit a gateway (or proxy)
> very well (by design) so don't do that.

Can’t disagree with that… in a previous mail, I think I said not to do
it unless you have a very good reason.

> Take the ePPN (or email address) that you get from the IdP

Bad example: ePPN is scoped, mail is not. mail attributes released by
an IdP will sometimes not match the “scopes” of the IdP (schools that
don’t issue email addresses to undergrads, merged companies with
multiple mail domains, schools within schools using subdomains,
contractors with gmail addresses, etc.).

> and convert it programmatically into an ePPN for which you (the gateway or proxy) are authoritative.
> For example, convert email address trs...@gmail.com into
> trscavo+...@mygateway.org. Same for an ePPN. In that way, only
> one scope is needed in gateway (or proxy) metadata and your SPs remain
> happy campers.

I have to disagree with this, in most cases. Rewriting scoped
attributes causes confusion, especially for attributes with
pre-defined values (like eduPersonScopedAffiliation). Developers
would need to know if their app was communicating with IdPs via a
proxy, or directly, because that affects the attribute values;
changing from proxy to non-proxy (or back) requires changes to the
app. Operations staff will need to reconfigure the SPs to handle the
new attributes - using eduPersonScopedAffiliation again, the default
rules for Shib SPs would filter out rewritten values like
"staff-exa...@exampleA.edu”.

My $0.02: NEVER proxy IdPs you do not control, unless you have an
agreement with the IdP owner(s) allowing you to proxy.

The one exception I’d make is for Social-to-SAML proxies, where the
attributes often need to be renamed and rewritten anyway.

Scotty

[pat...@cirrusidentity.com]

We’re using puppet to build docker images, then injecting
configuration via volume mounts and environment variables / files, so
we use environment variable all over our configuration; this enables
us to run the same idpproxy image on different subdomains against dev
and prod IdPs.  Additionally, our idpproxy image is just a few files
dropped on top of a base LAMP + SSP image, which already includes the
metadata for all our IdPs and proxies.  I’ll explain the environment
variables below:

I know I'm getting off topic here, but I'm curious how you decided to handle the SSP logs in the docker container.

Did you run syslog in the container as well? or log to file on a volume and then access the volume/logs from some 'log processing' container? other? 

[Scotty Logan]

On Fri, Nov 20, 2015 at 9:50 AM, <pat...@cirrusidentity.com> wrote:
> I know I'm getting off topic here, but I'm curious how you decided to handle
> the SSP logs in the docker container.
> Did you run syslog in the container as well? or log to file on a volume and
> then access the volume/logs from some 'log processing' container? other?

We use the same approach in most of our containerized apps - we send
the logs to stdout / stderr so that journald on the host system
collects them, then we run a Splunk forwarder container to send the
logs to a central Splunk server.

Scotty

[Scotty Logan]

On Fri, Nov 20, 2015 at 9:54 AM, Scotty Logan <s...@stanford.edu> wrote:
> We use the same approach in most of our containerized apps - we send
> the logs to stdout / stderr so that journald on the host system
> collects them, then we run a Splunk forwarder container to send the
> logs to a central Splunk server.

For other containers / services, we’re working on writing the logs to
volumes, then using the Splunk forwarder on those directories.

Scotty

[Shweta]

Hi,

Thanks a bunch to everyone here who helped with the direction on this. The Sign-in has been setup and works fine with the Proxy. I need to resolve a Logout issue though. 

All IDPs that Proxy interacts with send their logout url as an attribute. The attribute name is consistent from all IDPs. 

Any suggestions on where to hook in a call to the logout url for all IDPs for a user, when the SP brings a user back to the logout page at the Proxy. I was trying to see if a user is logged in the authenticate.php file. 

I would expect $as->isAuthenticated() should return true, but it doesn't.

https://proxy_url/simplesaml/www/module.php/core/authenticate.php?as=default-sp&logout

Thanks, 

Shweta