#218 B2B_LOGIC - transparent authentication

trunk
closed-accepted
modules (179)
5
2013-01-23
2012-04-10
Nick Altmann
No

New option:
auth_mode = 0 - normal authentication
auth_mode = 1 - transparent authentication

Passes authentication from one to another side thorough b2b.

Discussion

  • Ovidiu Sas
    Ovidiu Sas
    2012-04-10

    Controlling auth mode globally (via a module param) is a little bit restrictive.
    I would prefer having a variable the will will be set before initiating the b2b call. This will allow both authentication modes to coexist on the same server.

     
  • Nick Altmann
    Nick Altmann
    2012-04-10

    What do you think about change b2b_init_request parameters?
    First - scenario
    Second - FLAGS (I think it will be useful in future)
    Third-Sixth - scenario params

    And make first flag to manage authentication mode?

     
  • Ovidiu Sas
    Ovidiu Sas
    2012-04-10

    I would prefer a variable to be set.
    Even if auth mode would be controlled as a parameter for b2b_init_request, it must accept pvars and the work is pretty much there. Also, inserting a param in the middle of existing ones, will break forward compatibility (old scripts will no longer work with new opensips versions).

     
  • Nick Altmann
    Nick Altmann
    2012-04-16

    What do you think about new command, like b2b_set_flags("flags")?
    I think that there are more than one option (flag) will be needed in future.

    Something like:
    b2b_set_flags("T"); # transparent authentication
    b2b_init_request("top hiding");

    I think it would be better than just a variable.

     
  • I agree with Ovidiu on both things - it should not be a global option and it should be backward compatible.

    The only options I see here is either use a kind of module variable to set the flags before the init:
    $b2b_flags = xxxxxx ;
    or as Nick suggested, with a function, to do more or less the same.

    Another approach may be to quiz the flags in the first param, using a separator - this will be backward compat. Like:
    b2b2_init_request("my_scenario","","");
    ->
    b2b2_init_request("my_scenario/flags","","");

    Regards,
    Bogdan

     
  • Nick Altmann
    Nick Altmann
    2012-04-20

    Wow! I think flags in the first param is the best solution!

     
  • Ovidiu Sas
    Ovidiu Sas
    2012-04-21

    If we want this functionality implemented as a flag, then it shouldn't be passed as an extension to the first parameter because:
    - it's an awkward syntax
    - and it's really messy when you want to pass more flags.

    Best thing would be to set up the flag(s) before calling b2b_init_request and leave the syntax for b2b_init_request as is.

    Regards,
    Ovidiu Sas

     
  • Nick Altmann
    Nick Altmann
    2012-04-21

    Okay, let it be separate command and one-character flags.

    Like
    b2b_set_mode("A");
    A - Enable transparent authentication

    b2b_set_mode("AxSZ"); // For example

     
  • Nick Altmann
    Nick Altmann
    2012-04-23

    I've added per b2b session flags. And the first flag - "a" for transparent authentication.

    Usage:
    b2b_set_mode("a");
    b2b_init_request("scenario");

    It affects only this b2b session.

    The new patch attached in file opensips_b2b_transp_auth_v2.patch file.
    Also I attached opensips_b2b_lumpsbug_v2.patch that fixes lumps bug when opensips_b2b_transp_auth_v2.patch and opensips_b2b_lumps.patch (#3519778) applied together.

     
  • Nick Altmann
    Nick Altmann
    2012-05-29

    I've added updated version with fixed bug in late variables initialization. opensips_b2b_transp_auth_v3.patch It's production patch now.

     
    • assigned_to: nobody --> bogdan_iancu
     
  • Nick, sorry for this going back and forward on how this feature should be implemented . On my side, the final decision is have the flags in the first parameter (like b2b2_init_request("my_scenario/flags","",""); ) and not to add any new functions.
    Reasons: simplicity in usage and in coding.

    Let me know if you are willing to rework (again :D) the patch.

    Regards,
    Bogdan

     
  • Nick Altmann
    Nick Altmann
    2012-09-03

    Of course, I'll change it.

     
  • Nick Altmann
    Nick Altmann
    2012-09-04

    The new patch (v4).

     
  • Nick Altmann
    Nick Altmann
    2012-09-04

    And small patch for doc - opensips_b2b_transp_auth_v4_doc.patch

     
  • Anca Vamanu
    Anca Vamanu
    2012-09-05

    Hi Nick,

    I have looked also at this patch and my question is - is this patch really needed?
    What you are trying to achieve is to patch the authentication headers from one part to another, right?
    Have you tried putting in the custom_headers module parameter the authentication headers? Something like:
    modparam("b2b_logic", "custom_headers", "Proxy-Authorization|Proxy-Authenticate")
    I think I have tried this at some point and it was working.

    Regards,
    Anca

     
  • Nick Altmann
    Nick Altmann
    2012-09-05

    Hmm, it really works. I made patch because it doesn't work for me earlier.
    Anca, where were you 5 months ago? :-)
    Now it works for me with
    modparam("b2b_logic", "custom_headers", "WWW-Authenticate;Authorization")

    Possible it was bug, I think it fixed in commit number 9088.

    In my first patch was the same fix as in commit 9088.
    I did'nt try custom_headers param after my first (v1) patch.

    Ticket may be closed, but please, apply this small fixes to the documentation:
    - Then it can take at most 4 other parameters that represent the parameters for
    + Then it can take at most 5 other parameters that represent the parameters for
    the xml scenario. The expected number of parameters is also specified as an attribute

    - If you have a multi interface setup and want to chance the outbound interface,
    + If you have a multi interface setup and want to change the outbound interface,

     
  • Hi Nick,

    So this patch should be reworked just to offer the generic support for flags (which is used by the other patches) ?

    Regards,
    Bogdan

     
  • Nick Altmann
    Nick Altmann
    2012-09-05

    I'll include this support in #3520528, when I'll rewrite it. (It also depends on #3516387).
    I don't know any other patches that require flags support, except #3520528.

    I think that there is no need to include flags support into b2b_logic module when this support is not used (yet), isn't it?

     
  • Ovidiu Sas
    Ovidiu Sas
    2012-09-05

    I think there is a corner case where flags might be used.
    If the b2b modules are loaded with authentication support, then the modules will try to authenticate if credentials are found and if not, the challenge will be passed upstream.
    If we want to always force the upstream authentication, we might use a flag.

    But again, this is a corner case when local authentication is used/mixed with remote authentication.

    -ovidiu

     
  • Thanks for reworking the patch, I uploaded it on svn.

    Regards,
    Bogdan

     
    • status: open --> closed-accepted