Closed iay closed 9 years ago
I'm not sure I understand the generic approach mentioned in the previous comment but I will take an action item to write a JSON schema that could be used to complete this task. If nothing else, it will serve as a specification of sorts.
I had a chat with @rodwiddowson about the schema the EDS uses, and we came to the conclusion that the file describing it is not completely accurate, in that it doesn't seem to be a valid JSON schema. It's not used by any of the code, so it's essentially documentation but it needs a couple of tweaks.
However, it seems as if something along those lines (properly defined) with the addition of a flag on each entity saying whether it's an IdP or not would probably meet most of the use cases you had in mind. It will be a week or so before I get to that stage though (I'm working on #18 just now) so if you do come up with something more tailored that would definitely be useful.
Aforementioned (broken) EDS schema is here.
We'll start with something simpler, like this:
[
{
"entityID":"http://example.org",
"displayName":"this is the name",
"idp":true
}
]
The schema implied by the previous example doesn't seem to handle entities with multiple roles, an edge case that exists today in global metadata. Let's try this instead:
[
{
"entityID":"http://example.org",
"roles":
[
{
"type":"IdentityProvider",
"displayName":"foo"
},
{
"type":"ServiceProvider",
"displayName":"bar"
}
]
}
]
That assumes the English version of the mdui:DisplayName
(which I think we agreed is a shortcut we're willing to take at this time).
How about type
as the local tag name, i.e., SPSSODescriptor
and IDPSSODescriptor
? This would avoid inventing new names for things that already have them.
Agreed.
Initial implementation done as of f13fc92840df3515015bcd7280315559eda9fbb6.
One prerequisite to this would be #18 to avoid cache invalidation issues when using a shared item collection library.
It may or may not be worth putting part of the implementation for this in a
Pipeline
so that we can migrate over to a multi-MetadataService
and content negotiation approach if this proves to be interesting in the long term. The job being done is probably straightforward enough not to require this initially, though.I'm also in two minds as to whether it's worth looking at implementing this using MDA-77 as a generic way to generate arbitrary JSON without needing to tweak Java to change the schema. The simpler approach of just directly coding to the
javax.json
API is probably good enough to start with, though.