[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] more metadata questions...
> > 1. The <AuthnAuthorityDescriptor>, <PDPDescriptor>, and > > <AttributeAuthorityDescriptor> elements all include an > > <AssertionIDRequestService> so that relying parties can > > request a specific assertion from them. However, the > > <IDPSSODescriptor> does not provide a means to retrieve a Web > > SSO assertion by its assertion ID. For completeness, > > shouldn't this be included? > > Do we have such a use case? I consider such an IdP to be simply playing > the more traditional role of an authority. [RSP] I agree it's an authority role. But are you saying that to do this type of retrieval, you'd use the service defined in the <AuthnAuthorityDescriptor>? My point is that Web SSO assertions are often not the same as assertions that an Authentication Authority would create. They might contain both authn statements AND attribute statements. So a web SSO "authority" is really a different type of authority. > > > 2. On a related note, is it really likely that folks will > > want separate endpoints for retrieving assertions by their > > ID's based on the type of assertion that is being requested? > > I would think it's possible, and duplication isn't exactly a problem > anyway. In fact, we specifically went with the "duplication is better than > defaults and overrides" model with things like SOAP endpoints. [RSP] I'm okay with it as long as I can retrieve assertions by ID for any type of authority role I may define. > > Or if we want to restrict > > it just to asserting parties, it could be in a new > > higher-level type (e.g. an <AuthorityDescriptorType> or > > <AssertingPartyType>). This would permit the definition of > > other types of authorities later on (Credential Collector?) > > without having to duplicate this service element in all of them. > > That's a schema design issue, I suppose, but I don't think it matters that > much. I could add another super-type if people felt strongly about it. [RSP] I agree it's mainly a schema issue and don't feel that strongly about it. The main point was to point out the inability IMO to retrieve Web SSO assertions by their ID since they aren't the same as authentication assertions. > > > 3. On the call, it was agreed that we need to specify in > > the IDPSSODescriptor what saml:Attribute and attribute > > profile elements are desired for use in the Web SSO > > assertions. This makes sense for having an IDP describe what > > attributes it will send. But what about being able to > > describe what attributes an SP needs to receive? Should > > <RequestedAttribute> elements appear in the SPSSODescriptor? > > That's what the attribute consumer element is for. These are functional > roles but they're not mutually exclusive. If an SP wants attributes, then > it's also an attribute consumer. In fact, if I'm making a traditional > query, I can tell the AA what I want directly, I don't need metadata to > tell it. This element is *mainly* for the SSO case. [RSP] Hmmm. I didn't interpret it this way (i.e. intended for the SSO case) since a) it seems to have symmetry with the Attribute Authority role, which in our product is specifically for general attribute queries, and b) the WantAssertionSigned attribute in the <AttributeConsumingService> could conflict with the WantAssertionSigned attribute in the SPSSODescriptor. In our environment, I need to be able to describe whether to sign attribute assertions that I send back in response to general attribute queries. This is what I thought the <AttributeConsumingService> would be used for. It's less important to us to have an SP define via metadata what attributes it "might" query. In most cases it might seem odd, although it might be useful under certain conditions. Certainly for Web SSO, we need to be able to have an SP tell us what attributes they need our IDP to include in the Web SSO assertions we send them (I can't do it in the AuthnRequest and probably wouldn't want to do it there anyway). But this is distinct from the general attribute query settings. > > I separated it to reinforce the functional distinctions the metadata is > trying to capture so that other use cases that also had attribute > requirements can reuse it. That was partly why I didn't add the attribute > stuff to the IdP role. [RSP] I understand. But do you see why we actually need settings for general query support that are distinct from settings for SSO? > > > I suppose. I believe the easiest way to deal with this would > > be to change <RequestedAttribute> to be [Optional] instead of > > [One or More]. Here, I could specify an > > <AttributeConsumingService> element with the signing setting > > the way I way and interpret the absence of any > > <RequestedAttribute> elements to mean I'm interested in all > > attributes (subject to the usual policy controls). > > I can buy that, although these new capabilities in practice make it kind > of a weird idea to have a wildcard entry. Seems like if you can't tell the > responder what you want, he isn't going to know either. We used to say it > was out of band, but this is the out of band mechanism. ;-) [RSP] True enough. In my opinion, we should put an SP's desired Web SSO attributes in the SPSSODescriptor role definition and make the <AttributeConsumingService> describe settings that a relying party needs when it makes general attribute queries.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]