Help. I want one IDP and to specify the authentication source based on the service provider

74 views
Skip to first unread message

joe.young

unread,
Aug 4, 2016, 12:08:26 PM8/4/16
to SimpleSAMLphp



I am wanting to restrict access to a specific service provider. I have a hosted Identify provider and I am wanting to specify the authentication source based on the service provider.   I have two authentication sources. One of the sources authenticates to smaller subset of users.  Is there a way to do this? 

I currently have two IDP entries on the server with DNS names that start with sso. and sso2. Each IDP has a different authentication source. I would refer not to have multiple DNS names. 

Thank you,

Joe Young



Peter Schober

unread,
Aug 4, 2016, 2:40:42 PM8/4/16
to SimpleSAMLphp
* joe.young <joe....@orecity.k12.or.us> [2016-08-04 18:08]:
> I am wanting to restrict access to a specific service provider. I have a
> hosted Identify provider and I am wanting to specify the authentication
> source based on the service provider. I have two authentication sources.
> One of the sources authenticates to smaller subset of users. Is there a
> way to do this?

I see nothing in
https://simplesamlphp.org/docs/stable/simplesamlphp-reference-sp-remote
that would suggest one can configure an authsource for a specific SP.

While this is generally considered to be the wrong approach (the right
one being that the resource itself provides authorization) you can
prevent certain part of your constituency from accessing certain SPs
using the "autorize" modul in your IDP:
https://simplesamlphp.org/docs/stable/authorize:authorize
E.g. by adding it to the saml2-sp-remote.php metadata for a given SP.

> I currently have two IDP entries on the server with DNS names that
> start with sso. and sso2. Each IDP has a different authentication
> source. I would refer not to have multiple DNS names.

Do those IDPs share the same entityID? Either way, with the authorize
module none of that should be necessary.
-peter

joe.young

unread,
Aug 4, 2016, 3:11:43 PM8/4/16
to SimpleSAMLphp, peter....@univie.ac.at

The IDPs are hosted. Here is my  'saml20-idp-hosted.php'
---

$metadata['__DYNAMIC:1__'] = array(
        'host' => 'sso2.<DOMAINNAME>',
        'privatekey' => 'server.pem',
        'certificate' => 'server.crt',
'auth' => 'overdrive', ); $metadata['__DYNAMIC:2__'] = array( 'host' => 'sso.<DOMAINNAME>',
'privatekey' => 'server.pem',
'certificate' => 'server.crt',
'auth' => 'server-ldap',
);
---
Maybe this is an industry standard, But I would have preferred not to have separate metadata entries that tie authentication methods to DNS hosts.  Can't I have one single entry and have specify an auth source by service provider?


Joe

Peter Schober

unread,
Aug 4, 2016, 3:59:56 PM8/4/16
to SimpleSAMLphp
* joe.young <joe....@orecity.k12.or.us> [2016-08-04 21:11]:
> Maybe this is an industry standard

No, this is just wrong. (But then what works for you cannot be wrong.)

With dynamic entityIDs ($metadata['__DYNAMIC:1__']) that means you
have two seperate IDPs, with seperate entityIDs, i.e., globally unique
identifiers for a SAML entity.

That's not "an industry standard", that's highly unnsual and I'd also
not recommend it. Certainly not for a use-case of "authorizing"
subjects on behalf of the resource owner (the SP).

> But I would have preferred not to have separate metadata entries
> that tie authentication methods to DNS hosts.

That's also the ordinary way of deploying a SAML IDP: One SAML IDP
(not two).

> Can't I have one single entry and have specify an auth source by
> service provider?

Maybe you can. I just told you that at least I couldn't see from the
published documentation how that should work. But it may not even be
necessary:

* joe.young <joe....@orecity.k12.or.us> [2016-08-04 18:08]:
> I have two authentication sources.
> One of the sources authenticates to smaller subset of users.

If one authsource contains a superset of objects/accounts of the other
authsource having two authsources (and consequently two DNS names and
two entityIDs) seems unnecessary, and you should be able to do what
you want using a single authsource alone (the superset one), plus the
authorize modul where needed.

-peter

joe.young

unread,
Aug 4, 2016, 4:22:27 PM8/4/16
to SimpleSAMLphp, peter....@univie.ac.at

Thank you Peter..


I was tasked to set up this strange arrangement and I wanted to see how far I could push it.


Joe

Peter Schober

unread,
Aug 4, 2016, 4:30:02 PM8/4/16
to SimpleSAMLphp
* joe.young <joe....@orecity.k12.or.us> [2016-08-04 22:22]:
> I was tasked to set up this strange arrangement and I wanted to see
> how far I could push it.

Sure. If you wanted to file an issue for that in the issue tracker you
certainly can.
Personally I'd suggest using authentication context classes (cf. SAML
spec) as input to select an authsource, but why not also entityIDs.
-peter

joe.young

unread,
Aug 4, 2016, 5:40:31 PM8/4/16
to SimpleSAMLphp, peter....@univie.ac.at

This is close.. What does 'group' mean?  I want to specify the OU of allowed users.


'authproc.sp' => array(
		60 => array(
			'class' => 'authorize:Authorize',
			'regex' => FALSE,
			'group' =>  array(
				'CN=SimpleSAML Students,CN=Users,DC=example,DC=edu',
				'CN=All Teachers,OU=Staff,DC=example,DC=edu',
			)
	)

Peter Schober

unread,
Aug 4, 2016, 6:08:10 PM8/4/16
to SimpleSAMLphp
* joe.young <joe....@orecity.k12.or.us> [2016-08-04 23:40]:
> This is close.. What does 'group' mean? I want to specify the OU of
> allowed users.

From 1.3 "Attribute Rule":
https://simplesamlphp.org/docs/stable/authorize:authorize

"Each additional filter configuration option is considered an
attribute matching rule. For each attribute, you can specify a
string or array of strings to match. If one of those attributes
match one of the rules (OR operator), the user is
authorized/unauthorized (depending on the deny config option)."

So "group" in third example is the literal attribute name you'd
compare/restrict values for. I.e., for this to work in the simplest
case you'd need an attribute available (looked up from LDAP) with the
value to compare/restrict.

From your example I'm assuming want want to authorize based on group
membership?

> 'authproc.sp' => array(
> 60 => array(
> 'class' => 'authorize:Authorize',
> 'regex' => FALSE,
> 'group' => array(
> 'CN=SimpleSAML Students,CN=Users,DC=example,DC=edu',
> 'CN=All Teachers,OU=Staff,DC=example,DC=edu',
> )
> )

So there are several ways to deal with this, all depending on your
LDAP implementation and configuration.

In case the LDAP server stores (or "mirrors") group memberships in
the person's object (memberOf attribute, isMemberOf attribute,
something like that), that's the attribute you'd look up from LDAP and
put into your config (instead of "group" above). If you know it's
available in LDAP but not shown in SimpleSAMLphp that may be because
it's an operational attribute and those are only returned from the
LDAP DSA when explicitly asked for them. ('attributes' parameter in
the ldap:LDAP authsource, check the documentation.)

For example with OpenLDAP that's possible using the memberOf overlay.
Other LDAP implementatons may have comparable methods, you'd need to
be specific about your LDAP DSA.

For MS-AD (some or all) groups should be available in the 'memberOf'
attribute (but may be missing the user's primary group, from what one
can read on the net).
Also for MS-AD it may make a difference what port you query,
cf. "standard port" vs. "global catalog" at
https://wiki.shibboleth.net/confluence/display/SHIB2/LdapServerIssues#LdapServerIssues-MicrosoftActiveDirectory

In case you don't have group memberships stored (or reflected) in the
person's object, but your LDAP DSA supports at least the entryDN
operational attribute (something you can verify with a simple LDAP
search, e.g. using the ldapsearch command line tool), you can use
Macro's recipe posted to this list only *yesterday* (thread "Using
Group Authorization with OpenLDAP").
Following that method you'd first dynamically create an attribute
within SimpleSAMLphp based on an LDAP search for a person's group
memberships, then reference that attribute in the authorize:Authorize
authproc filter above.

-peter
Reply all
Reply to author
Forward
0 new messages