John Dennis wrote:
In the Web UI if you go to the admin page, then click on the
"Identity
Providers" tab, then click on "saml2 manage" you'll be brought to the
"Service Providers" page where there is a "Add New" clickable link
and a
list of existing service providers below it.
What I don't understand and would like someone to explain to me (because
I'm trying to modify the code) is why the template for adding a new SP
is a hand crafted page (templates/admin/providers/saml2_sp_new.html)
that only permits a slim set of the configuration options but if you
click on one of the links to view an existing SP (or edit it) and
entirely different template is used
(templates/admin/option_config.html). Unlike the template for adding an
SP this template is not specific to the data (e.g. adding a new SP),
rather it is a generic data driven template that populates itself from
the ServiceProvider config items. In fact the option config template
paradigm (templates/admin/option_config.html) is used in a variety of
places to build a config page.
So why does the NewSPAdminPage class have a significantly different
implementation than the SPAdminPage class?
Validation of the data is handled differently, the data that can be
specified is different and the generation of the HTML is different. Why?
Why am I asking this question? It's not just academic :-) I'm trying to
fix ticket #130 and also alleviate some of the major headaches we had
getting ECP to work in rippowan. We need to be able to show the SP
metadata on the SP config page and optionally allow it to be edited (if
it's not signed). This is because many SAML problems have their root
cause in the metadata and if you can't see (or fix) the metadata it's
really hard to diagnose the problem. The problem with implementing the
fix is the mechanism for specifying the metadata on the "New Service
Provider" page is entirely different from what the "Service Provider
Configuration" page uses and that's creating a lot of awkward weirdness
in implementing the fix. It seems like things would be much simpler and
more robust if the way you add an SP and the way you view an SP used the
same code and template. Is there some compelling reason they don't? Is
there some reason the two pages have disjoint sets of data that can be
specified?
Yeah, it's a bad situation and I've run into similar problems it's just
a rather huge task to tackle. I was going to bring that up for 1.3.
The whole writing and reading data is a nightmare right now using either
mechanism. I think the util.config method is the way to go forward we
just need to improve the import/export handling to hide the data
implementation better. The data normalization still leaves a lot to be
desired. There have just been bigger fish to fry.
That, and I think the new SP page will always need some extra hand
holding but it should still be possible to do a generic-ish page for it.
rob