Profile Configuration parsing

[Rod Widdowson]

I have been working on the parsing of RelyingParty.xml and I have just made
the first checkin.

There are few matters arising which I'd like us to consider.  We can close
them off here or take them into Friday's meeting as required.

1) Extra configuration

In general the impedance mismatch between the V2 Schema and the V3 class
hierarchy is much less than I had anticipated. However there are a few
mismatches:

a) I am not even considering anything in the Security schema for now.  We
may decide to jettison it in its entirety, or we may not.  For now the uses
that that ProfileConfiguration and RelyingParty schemas have are by
reference so our options are open to do pretty much anything.

b) Equally I do not think that now is the time to make the call on how to
handle the extra configuration that V3 brings.  We may do the embedded beans
thing, or references, or something else.  I propose that we wait until
Daniel reports back on how he gets on with the DataConnectors before we
discuss and decide this.

c) Meantime there are a few places where I hard- or soft- wire things up.
The most notable case was for the ArtifactConfiguration (URL and index).
These were AFAICS, taken from the Metadata in V2 and this is not an option
for V3.  For now I am just planting a reference to beans whose name is
derived from the precise configuration (for instance "
shibboleth.SAML2.Artifact.ServiceURL.   Other missing parameterizations
(e.g. encryptAttributeValues) just grab the defaults.

d) Apart from Security schema references (discussed above), the only
parameterization in the schema which is not available in V2 is the
attributeAuthority and as discussed yesterday non default values of this
will be warned about and then ignored.

2) Non schema-valid under property replacement

I'll note in passing that this parsing has exactly the same issues that
other schema have: namely that '${idp.boolean.property}' is not schema valid
for a type="boolean".  For the ProfileConfiguratrions, things are slightly
exacerbated because we also have "cryptoReqType" which converts the value
"always", "never", "conditional".  The fix here will be to relax the schemas
to be just strings, but I have not done that yet pending complete agreement
on doing so.

3) There is a mismatch in the comments the "Audience" elements of
SAMLPropertyConfiguration which states "List of audiences for issued
assertions." And the List<String> assertionAudiences field  in
AbstractSAMLProfileConfiguration which has the java doc "Additional
audiences to which an assertion may be released".  I'm pretty sure that
these are the same thing, but I wanted to check.

Thanks

Rod