My suggestion was mainly that what they're suggesting doesn't work
unchanged, it's not suitably secure, at least to the level of the existing
standard and the risks it built in mitigations for.
Thanks for your clarification. I understand and agree with this. The attributequery 'as is' is not a suitable candidate for the front channel binding without additional specifications.
The requirement to request attributes over a front end channel (either to facilitate consent or to allow for user interaction) if one that I encounter more often. A possible direction is to combine an AuthnRequest and AttributeQuery in one by extending AuthnRequestType with the zero or more <saml:Attribute>.
Processing rules (happy flow):
1. The original request (without attributes) is handled as specified by the Web Browser SSO Profile. The happy flow results in a saml:Response, including saml:Subject.
2. The original request (with attributes) together with the saml:Subject now form a subset of AttributeQueryType. Process this request as specified by samlcore. The happy flow results in zero or more Attributes.
3. Include the attributes of step 2 in the response of step 1 as an saml:attributestatement (or add to existing attribute statement in response).
This also seems to cater for the use case as outlined by Ian and Colin.
Is the need for such an extension felt by other participants as well?
Met vriendelijke
groet,
drs. Martijn Kaag
tel +31 (0) 88 01 20 222 | gsm +31 (0) 6 42 94 00 93 | skype
martijn.kaag-connectis
On Wed, Dec 10, 2014 at 6:45 PM, Cantor, Scott <> wrote:
On 12/10/14, 5:35 PM, "Martijn Kaag" <> wrote:
>You should specify the (requested) subject if you want additional
>attributes from an Attribute Provider. This user previously authenticated
>at the Identity Provider. For this, they currently envision an
>attributequery over a front-end channel (because they need user consent
>per attribute); I understood that your suggestion was to implement this
>as Web SSO instead.
My suggestion was mainly that what they're suggesting doesn't work
unchanged, it's not suitably secure, at least to the level of the existing
standard and the risks it built in mitigations for.
As far as what would need to be done to make SSO work, that apparently
needs more study. The use case of requesting attributes is easy.
Specifying identifiers in some kind of open ended way is a different
problem. In my comments back, I was just being clear about the fact that
SubjectConfirmation is simply NOT an option for that.
It may be that profiling BaseID is the answer. The way subjects are
expressed doesn't have to be a NameID, there's a bucket there in the
schemas that was put there precisely to allow that element to handle more
open-ended requirements.
-- Scott
www.connectis.nl | Postbus 975 | 3000 AZ Rotterdam | +31 (0) 88 - 0120 222 | KvK 24444001
Connectis ontwikkelt een nieuw platform en zoekt ervaren software engineers.
Kijk op www.werkenbijconnectis.nl voor meer informatie.
Connectis, FederateNow™ en ZorgverlenerOnline zijn handelsmerken van Connected Information Systems B.V.
Dit e-mailbericht en enige bijlage is uitsluitend bestemd voor de geadresseerde(n) en strikt vertrouwelijk. Aan dit bericht kunnen geen rechten ontleend worden. Op het werk van Connected Information Systems B.V. zijn haar algemene voorwaarden van toepassing.
