RE: [liberty-dev] Enterprise Portal question

To <>
From “Conor P. Cahill” <>
Date Mon, 26 Aug 2002 12:36:17 -0400
Importance Normal
In-reply-to < >

> the Enterprise. The Enterprise Portal already has control of 
> the UI, and the link to the external web site has been 
> dynamically created with hidden form fields that contain the 
> AuthNResponse or Artifact.

Actually, the Enterprise Portal has given up control of the 
UI once it sent the page to the browser, so the key question 
here is:  What is under the link button?

My $.02 is that it should be an unsigned AuthnRequest() to
the Enterprise's IdP with the correct SP identified (so that
when the user selects that link, the IdP gets the AuthnRequest
and then sends the user (via the specified mechanism) to the
SP's AuthnResponse consumption entry point.

If the Enterprise Portal is the IdP, then it could have generated
the page such that the browser post profile data is stored 
within the form presented to the user for each of the possible
SPs (i.e. if the user selects button a, which is associated with
SP ABC, the form has the complete browser post data for SP ABC
and the selection of that button causes this data to be posted 
to the SP).  I find this solution less than optimal for several
reasons including:

    a) the page would have several browser post documents on
       it at the same time -- not an ideal security situaiton.
    b) There is no control over how long the page sits there
       before the user selects an entry and so the data could
       be out of date by then (expired -- past NotGoodAfter).
    c) The generation of multiple, likely unused, signed 
       AuthnResponses is an unnecessary waste of resources.

Another option would be to have some magic URL link that,
when submitted to the IdP, was interpreted as an AuthnRequest
for a particular SP.  (Remember, the user *MUST* be brought 
to the IdP during the Authn process so that the IdP has a 
chance to check any state information that it may have stored
within the browser to maintain session information for the
user).  This solution does not provide any significant benefit
over the actual use of the AuthnRequest() and is non-standard
(so it won't work with other IdPs -- even an enterprise 
IdP upgrade).

So, my suggestion is to stay with the AuthnRequest() used as
I outlined above in the enterprise scenario (sans signature).
This gets you what you want (an AuthnResponse going to the 
SP without the need for the SP to perform the redirection) and
keeps within Liberty Protocols.

> the principal's name identifier etc. have been pre-agreed. I 
> see no reason at this point to bother with the AuthNRequest 
> message. A quick browse of the specs indicates nothing that 
> prevents this nor indicates that use of the AuthNRequest 
> message is mandatory. Thoughts?? Cheers

While I don't believe that the AuthnRequest is absolutely 
mandatory, I think that need for the user to visit the IdP
during the process pretty much mandates some action that 
may as well be an AuthnRequest -- with the possible change
that it is submitted by a different party (which is allowed
under the specification -- that's why the signature on the
AuthnRequest is a "SHOULD" not a "MUST").


Partial thread listing:

RE: [liberty-dev] Enterprise Portal question(continued)
 Conor P. Cahill (08/26/2002)
 John D. Beatty (08/26/2002)
 Conor P. Cahill (08/26/2002)
 Jonathan Sergent (08/26/2002)
[liberty-dev] 2 items for clarification in protocols and schemas document
(Jonathan Sergent)


Please enter your comment!
Please enter your name here