SAML SSP advice

[an...@redbullet.co.uk]

Hi

I currently have an app which has an SSP SP connecting to a 3rd party IdP (non SSP) which does IdP an initiated SSO to us. This all works well. 

We also have another app which we want to effectively daisy chain our SSP SP with but I am unsure what the best architecture should be for this. 

So the setup we have is

point A : IdP - 3rd party that initiates SSO

point B : SP running SSP which consumes from A and authenticates a user in the B app

point C : this app needs to allow users from B to login via SSO (this could run SSP)

What I am unsure of whether I should be running B as an IdP or is there is better way to effectively bridge from A to C via B? Or is there a much simpler way of dealing with this as B and C are on the same server? 

Thanks

Andy   

 

[Peter Schober]

* an...@redbullet.co.uk <an...@redbullet.co.uk> [2014-01-25 14:01]:

> point A : IdP - 3rd party that initiates SSO
> point B : SP running SSP which consumes from A and authenticates a user in
> the B app
> point C : this app needs to allow users from B to login via SSO (this could
> run SSP)
>
> What I am unsure of whether I should be running B as an IdP or is there is
> better way to effectively bridge from A to C via B? Or is there a much
> simpler way of dealing with this as B and C are on the same server?

That all depends on the details, e.g. what "users from B" means, as
according to my understanding of the above B doesn't have its own
identities but relies on identities provided by A, the IDP.

The usual case of using SAML would be to make all protected resources
into SPs (or Relying Parties, to what the IDP asserts) and externalize
authentication to the IDP.
So I'd install and configure a SAML SP (SimpleSAMLphp or otherwise) to
protect C and integrate it with IDP A.

SSO is purely a function between a user agent and the IDP, so by
making resources B and C both rely on IDP A, subjects will experience
SSO as long as the session tied to a HTTP Cookie specific to the IDP
in their browser is valid at the IDP.
-peter

[Andy Creed]

Yes I see what you mean although we cannot use A as the IdP for C. B does
have its own use base which is imported from A (for various reasons).

Andy

>--
>You received this message because you are subscribed to a topic in the
>Google Groups "simpleSAMLphp" group.
>To unsubscribe from this topic, visit
>https://groups.google.com/d/topic/simplesamlphp/tLULaUGaCGY/unsubscribe.
>To unsubscribe from this group and all its topics, 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/groups/opt_out.

[Peter Schober]

* Andy Creed <an...@redbullet.co.uk> [2014-01-26 14:21]:

> Yes I see what you mean although we cannot use A as the IdP for C. B
> does have its own use base which is imported from A (for various
> reasons).

Then why use IDP A for resource B if B has local users?
-peter

[Peter Schober]

* Andy Creed <an...@redbullet.co.uk> [2014-01-26 14:21]:

> Yes I see what you mean although we cannot use A as the IdP for C. B
> does have its own use base which is imported from A (for various
> reasons).

So subjects accessing B need to authenticate at A. And subjects
accessing C need to authenticate at B *and* should expierience SSO?

If you make B an IDP of its own (standalone, without using SAML IDP at
as authentication source) subjects will have two IDPs (A, B) to
interact with, and hence two IDP sessions and hence no SSO between IDP
A and IDP B.

On the other hand, if you make B both an IDP (for resource C) and an
SP (to IDP A), that would enable SSO fuer subjects accessing resource
B or resource C but then all authentication would happen at IDP A.

So I don't think your constraints can be met.
(Personally I also don't find them very sensible, so I'd use any new
integration as an opportinuty to clean up such constructs.)
-peter

[an...@redbullet.co.uk]

It is the case that I cannot use A as an IDP for C. What I would like to do is use B as an IDP for C but have B initiate (as IDP first) as they are already authenticated at B from A. 

What I cannot see how to do is build the SAML response from B to C if I do have B initiate the SSO. The documentation doesn't appear to cover this in the IDP first area. 

Andy

[Peter Schober]

* an...@redbullet.co.uk <an...@redbullet.co.uk> [2014-01-27 11:54]:

> It is the case that I cannot use A as an IDP for C. What I would
> like to do is use B as an IDP for C but have B initiate (as IDP
> first) as they are already authenticated at B from A.

Yes, but:

* Peter Schober <peter....@univie.ac.at> [2014-01-26 15:03]:

> On the other hand, if you make B both an IDP (for resource C) and an
> SP (to IDP A), that would enable SSO fuer subjects accessing resource
> B or resource C but then all authentication would happen at IDP A.

Either you have two IDPs (A and B) with no SSO between them.

Or you make SP B also an IDP, whose authentication is delegated to IDP
A. But even if B is a seperate IDP and will assert it's own SAML
responses (to C), it will depend on IDP A for authentication, hence
failing your requirement that you "cannot use A as an IDP for C" which
is what this will effect in.

> What I cannot see how to do is build the SAML response from B to C
> if I do have B initiate the SSO. The documentation doesn't appear to
> cover this in the IDP first area.

You don't build responses (SSP does that for you) and whether the
response is unsolicited or in reply to a request from the SP is
immaterial here, I think.

If you're saying IDP-first is undocumented, that's here:
http://simplesamlphp.org/docs/stable/simplesamlphp-idp#section_11
But there's no "B intiates the SSO", unless you're referring to the
authentction request to IDP A (which is where SSO would happen).
-peter

[Andy Creed]

Thanks for you help so far. Please see below on the last point.

Andy

If though we were to ignore A and just consider B as an IdP how do I
configure an IdP First to connect to a MySQL db? I.e. The user is
authenticated on B and then wants to visit C. How do I configure SSP to do
that? The documentation only refers to a URL with a query string. I need
to take the current authenticated user and have SSP build the SAML
response so that when that URL is initiated by the user it does the
necessary post to the SP at C.

Or is my understanding of how it works incorrect?


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

[Peter Schober]

* Andy Creed <an...@provun.com> [2014-01-27 17:59]:

> If though we were to ignore A and just consider B as an IdP how do I
> configure an IdP First to connect to a MySQL db? I.e. The user is
> authenticated on B and then wants to visit C. How do I configure SSP to do
> that? The documentation only refers to a URL with a query string. I need
> to take the current authenticated user and have SSP build the SAML
> response so that when that URL is initiated by the user it does the
> necessary post to the SP at C.

IDP-initiated (or SP-initiated, for that matter) has to start
/somewhere/. The subject will have to access a resource ("click on a
link") that will start the process. The documented URL is how you
tell SSP do that. Where you place a link to that URL is up to you.

If the subject is not yet authenticated (has no SSO session) at IDP B,
it will prompt for authentication (whether that is MySQL or something
else is immaterial here) and then send the browser off to the SP with
a SAML assertion included.

If the subject is already authenticated (has an SSO session) with IDP
B, the same as above will happen, minus the explicit authentication in
a HTML form at the IDP.

-peter

[Andy Creed]

Ah I see what you mean. So that leads to the next question. If the user is
authenticated via SSO from A does that mean they are authenticated at B as
well? If they are do we need to ensure that the SSO session expiry time is
large to allow them to visit B and not expire before they choose to visit
C?

Also, how do we insert other attributes into the SAML response from B when
the user clicks on the IdP first URL?

Andy

[Peter Schober]

* Andy Creed <an...@provun.com> [2014-01-27 18:10]:

> Ah I see what you mean. So that leads to the next question. If the user is
> authenticated via SSO from A does that mean they are authenticated at B as
> well?

I'm not sure what scenario (of the several discussed) you're referring
to here, specifically.

Also I find all of this of very little value to the SSP community, so
I'll stop here.

> If they are do we need to ensure that the SSO session expiry time is
> large to allow them to visit B and not expire before they choose to
> visit C?

There's nothing in the SAML standard or SimpleSAMLphp that will make
sure a session at an IDP will only expire after the subject has
accessed a certain SP.

Also, does that mean we're now back to using IDP A for users of SP C,
even though you said that cannot happen?

> Also, how do we insert other attributes into the SAML response from
> B when the user clicks on the IdP first URL?

IdP-first or not (i.e., SP-initiated) is immaterial for what
attributes get release. Just like IdP-first or not is immaterial for
how the IDP will authenticate the subject.
I don't know why people keep obsessing about IDP-first. (Probably
because they're mistaken in thinking IdP-first will give them some
shortcut or something, when it's just a crippled replacement for
proper initiation by the SP, with more effort for everyone involved,
and a worse UX).
-peter

[Andy Creed]

On 27/01/2014 17:50, "Peter Schober" <peter....@univie.ac.at> wrote:

>* Andy Creed <an...@provun.com> [2014-01-27 18:10]:
>> Ah I see what you mean. So that leads to the next question. If the user
>>is
>> authenticated via SSO from A does that mean they are authenticated at B
>>as
>> well?
>
>I'm not sure what scenario (of the several discussed) you're referring
>to here, specifically.
>
>Also I find all of this of very little value to the SSP community, so
>I'll stop here.

Let me explain the scenario further to avoid any ambiguity as much as
possible.


If a user has already been authenticated from an IdP at point A and they
have visited an SP at point via IdP first would they then be authenticated
for an IdP first to point C. I appreciate that my terminology might not be
accurate but that is because you are the export from whom I am asking help.

>
>> If they are do we need to ensure that the SSO session expiry time is
>> large to allow them to visit B and not expire before they choose to
>> visit C?

>There's nothing in the SAML standard or SimpleSAMLphp that will make
>sure a session at an IDP will only expire after the subject has
>accessed a certain SP.
>
>Also, does that mean we're now back to using IDP A for users of SP C,
>even though you said that cannot happen?

I am not sure to be honest as I feel whatever I try an explain is falling
short of enough information for you.

>
>> Also, how do we insert other attributes into the SAML response from
>> B when the user clicks on the IdP first URL?
>
>IdP-first or not (i.e., SP-initiated) is immaterial for what
>attributes get release. Just like IdP-first or not is immaterial for
>how the IDP will authenticate the subject.
>I don't know why people keep obsessing about IDP-first. (Probably
>because they're mistaken in thinking IdP-first will give them some
>shortcut or something, when it's just a crippled replacement for
>proper initiation by the SP, with more effort for everyone involved,
and a worse UX).

OK. So whether they are IdP first or SP initiated how do attributes get
set within a SAML response via SSP? Does that make sense?

Thank you for your help so far although I get the feeling you are losing
patience with my questions.