5:46 p.m.
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?
--
John