Moving metadata and authsource location to a centralized database
Brendan Curran
database table instead of metatdata/saml20-idp-remote.php and config/
authsources.php?
A project I'm working on requires the quick addition of multiple
remote IdP's through a web interface. While it would certainly be
possible to append configuration data to the above files
automatically, our software platform runs on many horizontally load
balanced machines and coordinating distribution of these files after
they are edited would be relatively difficult. I intend to store this
information in exactly the same format it's currently in (serialized
php) only in a centralized database table accessible to simplesamlphp
- each row will have an IdP id, a metadata column, and an authsource
descriptor column.
Can anyone save me some time by boiling it down to the places in the
code I'd have to insert database reading logic? I've identified the
authsource call stack on the login side from instantiation/
requireAuth('IdP Name') down to reading authsource info (getById('IdP
Name')), but it appears to have a different path for logout and I
assume the same will be true with the all important metadata reading
logic.
Can anyone who's attacked this before help out here? Or maybe Olav or
another maintainer could point out the tricky spots or identify the
call stacks for all use cases to help me get started?
A big thanks in advance,
Brendan
Peter Schober
> A project I'm working on requires the quick addition of multiple
> remote IdP's through a web interface. While it would certainly be
> possible to append configuration data to the above files
> automatically, our software platform runs on many horizontally load
> balanced machines and coordinating distribution of these files after
> they are edited would be relatively difficult.
You could also produce the metadata elsewhere (with whatever tools you
desire), sign it (optionally, but makes the next step secure) and load
it from all components over the network?
Adding IdPs should not involve editing any config files.
-peter
Brendan Curran
>
> You could also produce the metadata elsewhere (with whatever tools you
> desire), sign it (optionally, but makes the next step secure) and load
> it from all components over the network?
> Adding IdPs should not involve editing any config files.
> -peter
local SimpleSAMLphp Service Provider you must add the IdP's metadata
to the file metadata/saml20-idp-remote.php, and you must also add an
AuthSource entry in config/authsources.php. How can IdP's be added
without needing to edit these two files?
Brendan
Peter Schober
> I'm afraid I don't quite understand your comment, to add an IdP to a
> local SimpleSAMLphp Service Provider you must add the IdP's metadata
> to the file metadata/saml20-idp-remote.php, and you must also add an
> AuthSource entry in config/authsources.php. How can IdP's be added
> without needing to edit these two files?
We're usign
http://simplesamlphp.org/docs/1.7/simplesamlphp-automated_metadata
-peter
Kostia Grebelsky
I am getting some weird behavior where code stops execution on
SimpleSAML_Utilities::initTimezone();
Never gets into SimpleSAML_autoload, everything works fine up to that point.
Load XXXX is a line in SimpleSAML_autoload for debug purposes...as well as
file info line..
Load SimpleSAML_Error_Assertion
file
/var/sites/XXXX/lib/third_party/simplesamlphp/lib/SimpleSAML/Error/Assertion
.php
Locad SimpleSAML_Error_Exception
File
/var/sites/XXXX/lib/third_party/simplesamlphp/lib/SimpleSAML/Error/Exception
.php
Before Utils load...
Kostia Grebelsky
If I do phpinfo(); right before SimpleSAML_Utilities::initTimezone(); in
_include.php right after php info I would get
Redirect
You were redirected to:
https://ssotest.crsinc.com/simplesaml/module.php/core/frontpage_welcome.php
clicking on link will bring me to installation page, preceeded by php info
output again..
Before Utils load...
--
You received this message because you are subscribed to the Google Groups
"simpleSAMLphp" group.
To post to this group, send email to simple...@googlegroups.com.
To unsubscribe from this group, send email to
simplesamlph...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/simplesamlphp?hl=en.
Brendan Curran
solve, what I'm really looking for is all code paths (full call
stacks) that read from saml20-idp-remote.php and authsources.php files
to look up authsources or metadata by IDP_NAME. We're going to migrate
this data to a database and I'm trying to narrow the code changes down
to the most elegant solution (patch) possible.
Filesystem storage is simply not an option for us. If anyone has done
this before I would appreciate any help possible. If not, I hope a
maintainer with intimate familiarity of these call stacks and caveats
has some helpful advice. I would request it as a feature or report it
as an issue but we are (of course) working on a compressed time
frame.
Again, big thanks in advance,
Brendan
On Feb 15, 1:07 pm, Peter Schober <peter.scho...@univie.ac.at> wrote:
> * Brendan Curran <brendan.cur...@gmail.com> [2011-02-15 20:48]:
Kostia Grebelsky
From: simple...@googlegroups.com [mailto:simple...@googlegroups.com]
On Behalf Of Kostia Grebelsky
Sent: Tuesday, February 15, 2011 3:12 PM
To: simple...@googlegroups.com
Subject: Not autoloading SimpleSAML_Utilities in _include.php version 1.7
Before Utils load...
IT IS THE Zend AutoLoader that is conflicting I believe.
Peter Schober
> This is interesting but doesn't address the problem we're trying to
> solve, what I'm really looking for is all code paths (full call
Sure, it does. Your problem description (and hence your proposed
implementation to "fix" this) still seems to stem from a misconception
that you'd need to edit text files on several machines in order to add
(or remove) SAML entities. (Not that managing files on multiple
maschines and platforms is an unsolved problem itself, thanks to
cfengine, puppet and friends.)
Accessing a shared networked database is one way to deal with this.
Having all your machines pull the metadata over the network is
another. And, not irrelevant if you're not doing this just for the fun
of it, one that exists today and does not create a new SPOF or
mandates operating a highly available RDBMS. (Clustering HTTP
resources for GET requests is both trivial and dirt cheap in
comparison. Also no DBA required.)
-peter
Brendan Curran
We will have as many as 10^4 machines needing to access this data. Its hard for me to believe this hasn't been attempted already by someone in my position.
Again, the parsing logic will remain the same, it's the pieces that pull metadata and authsource information into memory that i need to change. Is no one of any help here?
Brendan
Peter Schober
> Ok, I'm not going to bother arguing with you except to say that
> leveraging a network share (NFS) (i believe metashare retrieves and
> stores metadata files in a filesystem folder on a cron) is an even
> worse Single Point of Failure than our already existing HA,
> redundant, 5-9's uptime RDBMS. We have that taken care of already,
> don't worry.
No idea what you're talking about. I never mentioned NFS and I never
mentioned metashare (whatever that may be).
I simply said that pulling metadata via HTTP exists today, is used by
thousands of SAML entities worldwide, and is both operationally
trivial and cheap to setup highly available.
-peter
Olav Morken
And how is the Zend autoloader registered? Does it not use the standard
PHP function spl_autoload_register()? If a framework does not use that
function, you will easily get conflicts between different autoloaders.
Also: Are you including www/_include.php from your own code? That is
not the recommended way of using simpleSAMLphp. Instead, from your own
code, you should load lib/_autoload.php. www/_include.php is for use by
files in the www-directory.
Regards,
Olav Morken
UNINETT / Feide
Olav Morken
> Again, the parsing logic will remain the same, it's the pieces that pull metadata and authsource information into memory that i need to change. Is no one of any help here?
There is no framework in place for doing what you want to do (i.e.
retrieve metadata in a database), so you are pretty much on your own. I
have some thoughts to making it possible to define custom metadata
sources, but I haven't found the time to try to implement it.
Also: Why do you need to change the authsources-configuration? Do you
have one authsource for each IdP? Is there a specific reason for why
you need that?
Brendan Curran
I have some thoughts to making it possible to define custom metadata
sources, but I haven't found the time to try to implement it.
Also: Why do you need to change the authsources-configuration? Do youhave one authsource for each IdP? Is there a specific reason for why
you need that?
Thanks for your help in advance, I really appreciate your efforts on such a quality product.
Olav Morken
> Thank you for responding Olav, I very much appreciate it. I'll answer each
> query inline:
>
> I have some thoughts to making it possible to define custom metadata
> > sources, but I haven't found the time to try to implement it.
> >
>
> Looking into it, would the metadata parts be as simple as reconfiguring
> getMetaDataSet() and getMetaData() in MetaDataStorageHandlerSerialize.php to
> look in a database table instead of a directory/file structure?
In theory, yes. Alternatively, you could create your own copy of that
class, and add your own class to MetaDataStorageSource::getSource().
Of course, both these local modifications are in no way guaranteed to
work for future releases of simpleSAMLphp.
> Is this the
> only endpoint I would have to worry about - filling the return
> array $ret[$entityId] = $md; from getMetaDataSet() correctly?
You only need the getMetaDataSet()-function if you use one of the
built-in IdP discovery services. If you do not use those, the
getMetaDataSet()-function can return an empty array.
> > Also: Why do you need to change the authsources-configuration? Do you
> >
> >> have one authsource for each IdP? Is there a specific reason for why
> > you need that?
> >
>
> Good question, I currently have different authsource entries for each IdP -
> is this redundant? I use the authsource name to call
> requireAuth('authsource-name') for the correct IdP. How would I maintain
> only one authsource entry but still uniquely identify different IdP's for
> each user at runtime? If so this might save me from trying to address that
> by changing the getById() method to look in a database...
You can start SSO to a specific IdP by using:
$as = new SimpleSAML_Auth_Source('default-sp');
$as->requireAuth(array('saml:idp' => 'idp-entity-id'));
However, note that this function will not check that you are currently
authenticated to that IdP; it will only check that you are
authenticated to one IdP. To determine the current IdP, you can do:
$idp = $as->getAuthData('saml:sp:IdP');
Brendan Curran
cron job to:
A. pull and convert the metadata from a central database and write it
to saml20-idp-remote.php (It is inserted to the DB using a separate
custom UI)
B. create unique SP's with one authsource entry for each IdP and write
them to authsources.php
This allowed me to use the basic requireAuth() call and
isAuthenticated() to guarantee at runtime that the user is
authenticated with their correct IdP. I may eventually look into using
the parameterized calls for IdP identification that you specified
Olav, using one SP for all IdP connections - however this solution
currently works well and gives me the flexibility to customize SP
instances if required.
Are there any security risks incurred by using the same certificate in
all SP instances?
Dick Visser
> Here are my changes (simpified, without my project related stuff). Green:
> changes, orange: old code to know where changes should go.
>
> file /lib/SimpleSAML/Configuration.php
> function loadFromFile
>
> //change begin:
You should try the "diff" command. It's great!
--
Dick Visser
System & Networking Engineer
TERENA Secretariat
Singel 468 D, 1017 AW Amsterdam
The Netherlands
Marooned .
Of course I know diff command. It was quicker for me to post like that. Also, in the future those files can change and line numbers will also change. This way (info about functions to change) it should be a bit more resistant to future changes.
Cheers
Peter Schober
* Marooned . <maroo...@gmail.com> [2013-04-19 20:59]:
produce the diff automatically (svn diff, or whatever), which can be
understood by anyone/anything without inventing color schemes (which I
didn't see anyway, as I don't read HTML email) and start/end
indicators only humans could parse. Also at least I have no intention
of learning another ad-hoc convention to do the exact same thing and
applying diffs your way means manual intervention, instead of leaving
the boring stuff to tools.
That's a solved problem, you're only re-inventing a solution, poorly.
> Also, in the future those files can change and line numbers will
> also change. This way (info about functions to change) it should be
> a bit more resistant to future changes.
get rewritten or removed. Then what? Inventing your own scheme does
not make that process failsafe.
-peter
Marooned
Diffs are good if anyone will want to apply them to their codebase.
I'm sure no one will take my changes 1:1 as I'm using Zend framework and specific db structure. The code was only posted to show the idea, hence no diff.
Ok, lets leave it here. Just wanted to save time those who look for similar solution. That's it.
Chill out.
EOT from my side.