Many thanks Conor
To help answer your first point, the developer has not taken short cuts this time and given a more detailed picture of the flow.
I haven’t had any time to look at this, so I’m hoping it’s Ok to follow.
Thanks also to Tom, John, Anil, and Leif. I am sensing from you we are streeeeeetching the standard here..)
Cheers
Colin
Business rules for the above steps
NZ doesn't have the concept of unique identifier. On successful authentication the logon service issues pseudonymous reference to the service agency which is unique to the service agency. As per NZ privacy laws the agencies must not share
pseudonymous references.
SAML consent can be used if each individual agency captures the consent. But in our case we would like the assertion service to have centralised consent functionality so that the individual agencies don't really need to build consent function.
This means of course, interacting with the user via a browser, to ask and receive consent.
So we have revised the flow below to take account of all the steps (no short cuts).
Steps:
1.
The user initiates a transaction at the service, which requires identity and address details from attribute providers;
2.
The user is re-directed to the logon service for an authentication;
3.
The user submits the credentials.
4.
The logon service returns the SAML2.0 assertion to the service agency (SAML2.0 Artifact binding).
5.
The service agency requests (what we are calling) ‘context mapping’ STS to map the SAML2.0 authentication assertion in step 4 to the assertion service domain.
6.
The context mapping service issues encrypted an SAML assertion which contains assertion service subject confirmation domain.
7.
The service agency redirects the user to the assertion service (SAML AuthnRequest). The request contains following attributes:
-
SAML Assertion obtained in step 6
-
Attribute names
- The user will be presented with the consent page. The user provides the consent for the transaction.
- The assertion service retrieves identity and address details from attribute providers by SAML Authentication assertion.
- The assertion service creates SAML assertion with the identity and address details as attributes and returns it to the service agency
If this is nay clearer, here are our questions again...
Questions:
Couple of questions on the step 7;
1.
Can we use any element in the authentication request to pass SAML assertion to the assertion service?
2.
Can we use <AuthnContextClassRef> element to pass attribute names in the authentication request to the assertion service?
3.
Currently the logon service is built using SAML WebSSO profile and we would like to use same SAML profile for attribute assertion service as it involves the same centralised concept/capture function. So is SAML WebSSO profile the right
profile for this sort of use case?
(seeing we can’t see how we can use Attribute Query as we need to carry the actual attribute names as well).
Cheers
Colin (for Venkat)
From: Cahill, Conor P [mailto:conor.p.cahill@intel.com]
Sent: Saturday, 2 June 2012 12:07 a.m.
To: Colin Wallis; 'Tom Scavo'
Cc: saml-dev@lists.oasis-open.org
Subject: RE: [saml-dev] FW: SAML 2.0 Authentication Request Questions
Colin,
One of the issues you have is the subject confirmation domain of the assertion received back by the Service Agency in step 4. A typical SAML IDP would generate an assertion for the Service Agency,
not for your Assertion Service SAML IDP (ASSI). So first step would be to get an assertion in step 4 that was usable at both the Service Agency and ASSI (or have a way for the Service Agency to ask the Login Service SAML IDP for an assertion for the ASSI
– such as the Liberty IDWSF Discover Service or Authentication Service).
Once Service Agency has an authentication Assertion for the ASSI, you could handle step 5 in two steps and be fully within the standard:
·
Service Agency sends unrequested AuthnResponse with assertion to Assertion consumer URL at ASSI.
·
ASSI processes the assertion and creates “authentication Session” associated with that assertion and returns handle (e.g. as a cookie)
·
Service Agency sends AuthnRequest for attributes containing said handle and the ASSI process said request.
·
ASSI Sends response with assertion and attributes.
The 2nd stage of this could probably more easily be handled with an AttributeQuery than AuthnRequest since that is actually what you are doing (as far as I can tell).
Conor
<snip>
CAUTION: This email message and any attachments contain information that may be confidential and may be LEGALLY PRIVILEGED. If you are not the intended recipient, any use, disclosure or copying of this message or attachments is strictly prohibited. If you have received this email message in error please notify us immediately and erase all copies of the message and attachments. Thank you.
====