[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [saml-dev] drfat-catalyst-interop-plan-02
Hi Bhavna, > From: Bhavna Bhatnagar [mailto:bhavna.bhatnagar@sun.com] > In the above I am assuming that the authentication authority is actually > the > Issuer per the Assertion schema. Currently we at Sun put the sourceID > there . Is > that acceptable by all ? or should we have a more understandable string > there > like dns-suffix sun.com. While the authn authority is the issuer, SAML doesn't require that the issuer be the same system as the SAML SOAP Binding Responder. The SourceID which is defined as part of the B/A Profile identifies the system to which the samlp:Request should be sent via the SOAP responder. In our environment, the Issuer (SAML Authority) and SAML SOAP Binding Responder can be (and probably are) on different systems, so we don't expect to use the same identifier for both Issuer and SourceID. Our SAML responder may eventually handle SOAP binding requests and responses for multiple authorities. That said, we will use an IDType Base64 string for the Issuer string. Thus we don't rely on a more understandable string. I hope this works for the other vendors also and I hope that having different identifiers for Issuer and SourceID will word for you. > D. Unauthenticated users are re-directed to the portal for login. > > In D above, I am not sure what is the expected behaviour. If we redirect > to portal login, then after logging in, one would be displayed a content > page > with links to content hosted at distinct web sites, but I would think > that the user would expect to be taken directly to > the content application after a successful login upon redirection. Does > anyone think alike or if not can someone please clarify the expected > flow ? I think what was intended was just what is says - an authenticated user hitting the content provider will get redirected to the portal for login. However, the description should say more about what happens next. After authenticating the user, the portal could have 2 choices. First, the portal could display the links page that refers to the ISX (inter-site transfer) service. The user would then have to click to get back to the original content provider. Of course the click really gets them to the ISX with a TARGET= parameter and the ISX creates the artifact and sends them to the remote artifact receiver URL. That then gets them to the content application once the assertion is retrived. Obviously, getting the links page and clicking on it isn't very user-friendly. However, if the content provider redirects to the portal AND supplies a TARGET= parameter on the redirect, the portal could authenticate the user and transfer directly to the ISX service with the supplied TARGET= parameter. The user would then not have to see the links page. As in the normal case, the ISX would create the artifact and send the user back to the remote SAML artifact receiver. Once the assertion is retrieved, the user will see the content provider page they wanted. The 2nd scenario is more user-friendly, but it requires a vendor's content site to redirect to the portal with the TARGET= parameter. Can other vendors do this? I am planning for us to handle either method. Prateek, could we update the scenario to describe this or do we have to just stick with the first method?
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC