Re: SimpleSAML and multi domain / cross domain SSO

[Jaime Pérez Crespo]

Hi Valery,

On Nov 8, 2012, at 10:17 AM, Valery Fremaux <valery....@gmail.com> wrote:

Hi Karthik,

did you finally found a way ?

Im digging deep in SimpleSaml in quite a similar situation, distinct top domains to authenticate and federate on the same server, i.e. one SimpleSAML implemantation on the server and several SP mapping to IDP (via authsource.php) that use distinct domains. There is actually a mess in session handling that leads to the well known Lost State issue (well i'm guessing it is the reason, without technical evidences yet).

Could you be a bit more specific on how are you trying to setup this? I mean how you connect your applications to the SPs, how many instances of simpleSAML you have and where, and how have you setup SSP at each side.

The usual way it works is that you connect your PHP application to a SSP instance acting as an SP (you could also use applications written in other languages if you use AuthMemCookie). Each SSP SP exchanges metadata with another SSP instance acting as an IdP. That's how you achieve Single Sign On across multiple domains (which is the main idea of SSO after all).

Since SSP is configured with PHP files, it's also possible to have one single instance serving as an SP for multiple domains virtually hosted in the same server. I can provide you more info about that if you want, but it's quite difficult without a clear picture of what you want to achieve and how you are trying to do it.

Regards,

--

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

[Jaime Pérez Crespo]

Hi Stephan,

On Nov 8, 2012, at 10:38 AM, Stephan D. <denke...@googlemail.com> wrote:

Hey,

the same here. I think this should be the same topic so I put my question right here :)
I'm new to simplesamlphp ant want to develop a single-sign on like that:
- one idp (domain1)
- one sp (domain 2)
- app1 (domain3) and so on.

The SP is some kind of front-end or "translator" for the applications to be able to talk SAML to the IdP. Therefore, the SP and the application itself must both be under the same domain. You could have a SP in a different domain than the apps, but in that case it will act as some kind of proxy, and you'll need a way to communicate and exchange authentication data between it and the apps themselves, which is kind of non-sense since you are making it much more complicated than it needs to be.

The SP is able to communicate with the idp fine (by using the simplesaml install page).

But the application does not.My first problem was, that the  idp does not know the application, so i added the app to saml20-sp-remote.php, which looks a bit strangebecause the app has nothing to do with simplesaml (except of 3 Lines to authorize) and the url looks like a simplesaml one.

That's because the app should not talk to the IdP directly, but should delegate that to the SP. Your apps should make use of the SSP API to trigger authentication if needed, and/or gather authentication status and attributes from the user. You don't need to add any information about the application itself in the IdP.

After that I can authorizise with success but instead of redirect I get a no_state error.

What I guess is happening here, according to the scenario you depicted before, is that you are loosing your state information because you are redirecting to a different domain than the one that initiated the login. If you have SP in one domain and apps in different domains, but same server after all, you might be triggering authentication from the domain of the SP, but redirecting back to the apps as you configured it that way in the IdP. That's entirely wrong, because different domains mean different cookies and therefore different sessions.

Somy question: Can I do something? Maybe the mistake is in the way I trie to inform the idp about the applications or do I need one SP for every app?

Exactly. If your apps are in different domains, then you need a different SP for each of them (which does not necessarily mean different simpleSAML instances). Both the app and the SP should be under the same domain, but if all your apps are in the same server with different virtual hosts, you can easily configure simpleSAML to act as SP for all of them. You just have to fetch the current virtual server options (domain, port, base path and so on) at the beginning of the config.php file, and build the 'baseurlpath' property according to these options.

Regards,

[Stephan D.]

Dear Jaime,

thank you very much for your detailed answere.
I think I understood most and have a very simple single sign on running.
But: At the moment I have 3 instances of simplesaml and this does not look serious to me.

One for the idp, an one for every app. So you wrote:

Exactly. If your apps are in different domains, then you need a different SP for each of them (which does not necessarily mean different simpleSAML instances).

How do I reach this. I've got the application in the www-folder. For me it's not clear how do I have to setup everything: Now my Directory looks like this

• htdocs
• simplesaml
• idp
• all the simplesaml-stuff
  
• sp1
• all the simplesaml-stuf
• sp2
• all the simplesaml-stuff

Can you give me a tip, how can I setup more SP's with one instance? Maybe I just make changes in the www-folder and put the other stuff somewhere else?
Btw. I'm using xampp with windows 7....

Big thanks,

Stephan Denker

On Thursday, November 8, 2012 11:52:20 AM UTC+1, Jaime Pérez wrote:

Hi Stephan,

On Nov 8, 2012, at 10:38 AM, Stephan D. <denke...@googlemail.com> wrote:

Hey,

the same here. I think this should be the same topic so I put my question right here :)
I'm new to simplesamlphp ant want to develop a single-sign on like that:
- one idp (domain1)
- one sp (domain 2)
- app1 (domain3) and so on.

The SP is some kind of front-end or "translator" for the applications to be able to talk SAML to the IdP. Therefore, the SP and the application itself must both be under the same domain. You could have a SP in a different domain than the apps, but in that case it will act as some kind of proxy, and you'll need a way to communicate and exchange authentication data between it and the apps themselves, which is kind of non-sense since you are making it much more complicated than it needs to be.

The SP is able to communicate with the idp fine (by using the simplesaml install page).

But the application does not.My first problem was, that the  idp does not know the application, so i added the app to saml20-sp-remote.php, which looks a bit strangebecause the app has nothing to do with simplesaml (except of 3 Lines to authorize) and the url looks like a simplesaml one.

That's because the app should not talk to the IdP directly, but should delegate that to the SP. Your apps should make use of the SSP API to trigger authentication if needed, and/or gather authentication status and attributes from the user. You don't need to add any information about the application itself in the IdP.

After that I can authorizise with success but instead of redirect I get a no_state error.

What I guess is happening here, according to the scenario you depicted before, is that you are loosing your state information because you are redirecting to a different domain than the one that initiated the login. If you have SP in one domain and apps in different domains, but same server after all, you might be triggering authentication from the domain of the SP, but redirecting back to the apps as you configured it that way in the IdP. That's entirely wrong, because different domains mean different cookies and therefore different sessions.

Somy question: Can I do something? Maybe the mistake is in the way I trie to inform the idp about the applications or do I need one SP for every app?

Regards,

[Stephan D.]

Ok, I think I got it :)

[Jaime Pérez Crespo]

Hi,

On Nov 9, 2012, at 10:07 AM, Stephan D. <denke...@googlemail.com> wrote:

Ok, I think I got it :)

Good!

Anyway, I've done this in the past in two different ways, so two hints:

- Use symlinks for each SSP instance, and keep different config/ directories for each one. That's very flexible if you want to configure in a different way, but will be a pain to update and manage in general.

- Use PHP code in config.php to detect the virtual host and configure SSP dynamically according to the virtual host you're in.

Hope this helps!