Our engineering team had a number of questions/comments on
metadata:
- The <EntitiesDescriptor>
element permits nesting of one or more <EntitiesDescriptor> element(s)
inside it. It would be helpful to have some description of what
semantics are intended when this is done. For example, how do the
various attributes (e.g. validUntil) get inherited by the child
<EntitiesDescriptor> elements and their children?
- According to schema you can
have any number of <RoleDescriptor>, <IDPSSODescriptor>, …
elements inside an EntityDescriptor. The assumption is that this is
because a single entity can take on any of the roles. However, there
isn’t any normative text saying that you can only have one of each
of the various role descriptors. So what would it mean if an <EntityDescriptor>
element contains multiple <IDPSSODescriptor> elements, each with
different settings? Is this allowed?
- There is no metadata to
indicate that an entity supports the URI protocol binding. Should we add
something for this?
- It may be difficult to work out
with the current structure, but the current inclusion of certain
attributes and elements in the metadata mean that the setting has to apply
to all trusted partner connections and in our experience, this is often
undesirable. For example, the “WantAuthnRequestsSigned”
attribute on an IDPSSODescriptor means that ALL partner sights must comply
with the setting. If omitted it as declared to be false. I may
need to have some SP’s connect with unsigned requests and other SP’s
connect with signed requests. It’s worse when looking at the “AuthnRequestsSigned”
attribute of the <SPSSODescriptor> element. My SP may have many
different IDP’s. What if one IDP requires signed requests and
another requires they not be signed. This seems to require a
complete coordination of settings across all IDPs and SPs in a realm and
this seems quite unrealistic. We could potentially deal with this by
permitting multiple copies of the role descriptor elements, each with
different settings (see #2 above). However, if there are multiple
IDPSSODescriptor elements, we currently would have no way to determine
which one applies to any particular message exchange.
- The metadata doesn’t help
define Web SSO arrangements where the SSO assertions should carry one or
more AttributeStatements. [Of course, neither does the AuthnRequest
protocol.] This is a very common configuration and figuring out how
to represent this in metadata would be useful.
- Separate from #5, if a web SSO
exchange DOES carry attributes (even though it’s not defined by metadata),
AND an AttributeAuthorityDescriptor is defined, we assume that use of the
attributes in the first case is completely separate from declarations
within the AttributeAuthorityDescriptor. For example, we assume it is
valid to push attributes in an SSO assertion that are defined by one
profile even if the AttributeAuthorityDescriptor indicates that it doesn’t
support that profile.
- We provide no guidance on the
use of multiple endpoint declarations for the same service when the
endpoint is defined with EndpointType (i.e. it isn’t an
IndexedEndpointType). For example, for the SingleSignOnService
element in the IDPSSODescriptor is of type EndpointType but allows more
than one to be specified. How does an SP choose which one to use when more
than one is present?
Rob Philpott
Senior Consulting Engineer
RSA Security Inc.
Tel: 781-515-7115
Mobile: 617-510-0893
Fax: 781-515-7020
mailto:rphilpott@rsasecurity.com
|