Hi, The purpose of this e-mail is to document a proposal that aims at modifying the auth plug-in strategy to reduce plug-in interdependencies and to make it more streamlined. This effort stems from XECS-687 which revealed the hidden interdependencies between the TransferControl and EnforceAuthRules auth plug-ins A quick fix was done to address XECS-687 in a timely fashion but this proposal documents a more general fix that addresses the root cause of the problem and is in line with Scott's expressed wish of "...[moving] the addition of the auth parameter out into the authproxy code that calls the authplugin chain so that authorization by any authplugin causes the auth parameter to be added". For those who are interested in learning more the plug-in interdependency problems of the existing approach are encouraged to read comment 'Robert Joly 2008-11-19 12:16' of XECS-687 which steps through one such scenario.
In the past, EnforceAuthRules was the only plug-in that had the responsibility of authorizing requests and 'marked' authorized requests with a special signed parameter to avoid re-authenticating in-dialog requests unnecessarily. With recently added and upcoming features, more auth plug-ins have the ability of authorizing a subset of requests. As a consequence, the mechanism used by EnforceAuthRules to 'mark' requests as being authorized must be moved to a more generic point so that it can benefit all auth plug-ins. The rest of this e-mail details the component changes proposed to achieve this. The proposal mainly affects two components (SIpRouter and EnforceAuthRules) and has side-effects on one (TransferControl). This section will describe the proposed changes for all three components. EnforceAuthRules ================ The EnforceAuthRules is the plug-in responsible for enforcing that requesting users have sufficient permissions to complete the call they are initiating. In its current form, after the EnforceAuthRules determines that the requesting user is authorized to complete the call (based on authenticated Ids and permissions), if the request is dialog-forming, it encodes an 'auth' parameter in the Record-Route's RouteState proprietary parameter and return ALLOW. The main purpose of this encoded 'auth' parameter was to have EnforceAuthRules skip the whole authentication process for In-dialog requests whose initiation has already been authorized. The proposal suggests the following change to EnforceAuthRules: - EnforceAuthRules logic will no longer rely on the encoded 'auth' parameter. More specifically, it means that it will: a) no longer check for the presence of the 'auth' parameter in the RouteState b) no longer add an 'auth' parameter to the RouteState of authorized dialog-forming request - EnforceAuthRules will continue to do nothing when 'prior result' is something other than CONTINUE. Changes to SipRouter ==================== SipRouter is the component that calls the auth plug-in chain. When a request to be passed through the auth plug-in chain is received, the SipRouter will look at the RouteState to see if it contains a valid 'auth' parameter. IF it does NOT contain a valid 'auth' parameter then the auth plug-in chain is called with 'prior result' set to CONTINUE. At the end of the plug-in chain, if the 'final result' is ALLOW then SipRouter will add the 'auth' parameter to the RouteState. If the request has an authenticated Id, the value of the 'auth' parameter will be set to that Id, otherwise it will remain value-less. Note: the logic to determine the 'final result' remains the same. On the other hand, IF it contains a valid 'auth' parameter then the auth plug-in chain is called with 'prior result' set to ALLOW and 'authenticated identity' set to the value of the 'auth' RouteState parameter if a value had been set. These changes to SipRouter modifies the set of 'prior results' that some plug-ins can expect to see. As a general guideline, auth plug-ins should be prepared to handle all 'prior result' values, i.e. CONTINUE, ALLOW and DENY. Changes to TransferControl ========================== The proposed changes above have an incidence on the existing TransferControl plug-in. With its current logic, the TransferControl plug-in does nothing when it is consulted and the 'prior result' is ALLOW. This will have to be changed so that it adds a sipXAuthIdentity header parameter to Refer-To headers of REFERs-without-replaces. This change is required because, under the proposed logic, the TransferControl plug-in will sometimes be called with a 'prior result' == ALLOW which couldn't happen before simply due to the ordering of the plug-ins. Thank you in advance for your comments, bob _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
