Re: Application to Application authentication models....

From: r s (richard.scottat_private)
Date: Fri Jan 31 2003 - 08:10:57 PST

  • Next message: NESTING, DAVID M (SBCSI): "RE: Application to Application authentication models...."

    
     ('binary' encoding is not supported, stored as-is)
    In-Reply-To: <4ABF0315D817AB4EAD6224C31961A08C01276DC4at_private>
    
    
    <snip>
    >The web application generally doesn't need access to workflow states,
    >revision histories, etc.  In other words, for a public-facing application,
    >you should be comfortable if that application's back-end or database ID's
    >had no passwords to begin with.  If you feel that this approach would
    >compromise the security of your application, then you might want to look
    >into why that is (maybe you have too much business logic in your
    >presentation layer, for instance).
    </snip>
    
    I disagree in part.  The very fact that the security credentials have to 
    be stored on the filesystem to me, means that there are two possible 
    issues - (a) a breakin at the web layer could lead to a comprimise of the 
    data withint he database. (b) connections to the database could be made 
    from inside the enterprise, pending firewalls etc.
    
    >
    >With that issue addressed, securing the application's credentials becomes
    >less of a worry.  You have to assume that if someone can break into your
    >server and take control of it, the intruder can do everything that the
    >application can do, including pulling credentials off of a separate LDAP
    >database and using those to further their interests.  While you can put
    >speed bumps in their way by using SSL-encrypted LDAP sessions, stashing
    >credentials directly in binaries, etc., I don't know that those solutions
    >are going to buy you much more in the way of security.
    
    
    I accept that this may be the case for web applications per machines.  
    What if I have two separate applictions running on the same physical box, 
    one uses  very highly sensitive database the other does not.  How can I 
    authenticate the two processes without resorting to basic user id's and 
    passwords being stored on the filesystem?
    
    
    >
    >Though continuing on this trend, any sensitive traffic from your DMZ 
    servers
    >to your back-end systems should be SSL encrypted anyway, where "sensitive"
    >includes traffic with usernames and passwords in any form.  Sometimes the
    >simplest way of approaching all of this is through the use of SSL
    >certificates, authenticating *both* ends of a session.  If you're going to
    >use SSL anyway, why not use an authentication system built into SSL?  
    (This
    >includes access to databases, LDAP, etc.)  And always keep in mind that
    >you're just authenticating the system, which could always be under the
    >control of someone else.
    
    
    The use of SSL on database connections is considerably high.  I am not so 
    worried about passive attacks.  I am wondering if there are any frameworks 
    that exist such that when I take code and run this in production it can 
    authenticate against a directory service, and obtain permission to access 
    resources.  I can take the same code run it on the DEV box and intrsically 
    connect to the DEV database systems.
    
    It's much like Kerberos for applications to authenticate against 
    applications.
    
    What my requirements would be is that the code itself could identify where 
    it was being executed.  This information is passed to the directory 
    service and the directory service gives the necessary credentials to 
    access resources in that environment.
    The problem is, the application needs to authenticate to the directory 
    service.  Using certs just binds all applications, potentially, at teh 
    physical machine layer, not at the application layer.  And accordingly, we 
    are left with storing passphrases on the file system.
    
    Any other comments would be great?
    
    Cheers
    r1.
    >
    >My two cents, at least.
    >
    >David
    >
    >
    



    This archive was generated by hypermail 2b30 : Fri Jan 31 2003 - 11:00:34 PST