Topic
  • 3 replies
  • Latest Post - ‏2013-04-23T00:54:46Z by Rohit-Goyal
chauhan_vin1
chauhan_vin1
24 Posts

Pinned topic Username token

‏2013-04-18T00:05:29Z |

Hi,

I am planning to setup communication between two Datapower boxes(A & B) in a way that for a particular application D/P(A) is connected to D/P(B).

D/P (A) would be the entry point of the requests and D/P (B) which provide access to internal services would be contacted by D/P(A) to service the request.

I need to make sure the D/P(B) will only accept request from D/P(A) -

Please provide some insight which would be a better and effective solution.

1. Implement two way SSL between D/P(A) and D/P(B) - with D/P(B) in Reverse mode, but I dont want to block hardwire D/P(B) only to accept D/P(A)s client certificate on port 443. As D/P(B) and the services it facades can be accessed by other application directly on 443.

2. I am planning to set up username token between D/P(A) and D/P(B) - Any idea how can this be implemented of would it really be a right approach with considering the performance issues of WS-Policy.

3. Any other approach ?

  • PaulGlezen
    PaulGlezen
    3 Posts

    Re: Username token

    ‏2013-04-19T14:09:53Z  

    If you implement UNT, you must store the password somewhere on your D/P(A) in order to send it to your D/P(B).  (You may have to store it on B also, unless you implement some kind of hashing solution).  This makes some people nervous; you get the same problem if you have to send BasicAuth info to another system.

    With the two-way SSL, DataPower keeps the private key secure.  This makes auditors happy.  The drawback is that you have more certificates to manage.  Changing the password amounts to regenerating and distributing client certificates.

    So "better and effective" depends on what your organization can afford with their budget, implement with their skills, and manage with their tools.

  • kenhygh
    kenhygh
    1523 Posts

    Re: Username token

    ‏2013-04-22T11:05:43Z  

    I've done this a few ways.

    1) DP(B) does IP address filtering, only accepting requests from DP(A). This is susceptible to IP spoofing, but is pretty reasonable within an enterprise. This is also inflexible - if something in the network changes, you have to update DP(B). Also, if you have a load-balancer in between DP(A) and DP(B), depending on its configuration DP(B) might see the load balancer's IP address rather than DP(A)'s address.

    2) use a shared secret on DP(A) and DP(B). DP(A) encrypts a string (we used a datetime) and puts it in an HTTP header. DP(B) only accepts requests with the header that it can decrypt. 

    3) As Paul mentions, 2-way SSL. This is pretty simple to setup, but if you move machines in and out of DP(A) and DP(B), you may get into certificate management overhead.

  • Rohit-Goyal
    Rohit-Goyal
    133 Posts

    Re: Username token

    ‏2013-04-23T00:54:46Z  

    We have done this using "two way ssl". Setup a SSL profile on DP(B) accepting requests coming with client certificate signed by Internal CA. That way we have multiple consumer having different cert accessing port 443. DP(B) verified and allowed access if incoming client cert is signed by an Internal CA.

    For authorization, we extracted the CN of client cert and verified against a manifest file.