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