Symantec Access Management

  • 1.  PS: Storing a password

    Posted Feb 12, 2016 02:53 AM

    Hi guys,  I've got this problem:


    I need to store an encrypted password, that would be easily recovered by Policy Server, decrypted and send in Response.

     

    In your opinion what would be the best solution for this case? How would you resolve it?



  • 2.  Re: PS: Storing a password

    Posted Feb 14, 2016 01:33 AM
    Active response seems to be the best solution where  you do the custom decryption 




  • 3.  Re: PS: Storing a password

    Posted Feb 17, 2016 01:10 AM

    One more thing: In order to encrypt / decrypt users passwords stored in RDBMS we would like to use Policy Server’s keys (Password Encryption Key) and ideally Policy Server encryption algorithms (AES). However it’s not clear how this should be implemented - e.g. how passwords should be encrypted during users provisioning (registration) and then Policy Server configured for decryption. Any links to documentation / examples would be highly appreciated.



  • 4.  Re: PS: Storing a password

    Posted Feb 17, 2016 09:05 PM

    mwegrzyn

     

    Before I suggest this, I am totally against sending passwords in response. This defeats all security definitions / frameworks. We should not be doing this.

     

     

     

    What passwords are we talking here? User Passwords?

     

    If we are talking about User Passwords, then the ENCRYPTION ALGORITHM is controlled by User Store (i.e. LDAP or ODBC Product being used).

     

    CA SSO does not handle User Password ENCRYPTION / DECRYPTION OOB.

     

    Have you checked if the Password are stored by User Store as ONE WAY HASHING ALGORITHM or TWO WAY HASHING ALGORITHM - if it is ONE WAY HASH ALGO, there is no way to retrieve the clear text password.

     

    Hence the first step for such a requirement is to understand the way User Password is stored by the User Store. If the User Store allows for retrieving password back as Clear Text (i.e. provided the User Store support TWO WAY HASHING ALGORITHM); then CA SSO could read it like a normal user attribute and pass it back as a clear text (not good not good) header response.

     

     

     

    Regards

     

    Hubert



  • 5.  Re: PS: Storing a password

    Posted Feb 24, 2016 04:23 AM

    Problem is that we need to pass this password as open text (over ssl). And we're trying to figure out what would be the best way to store it securely, that Police Server could easily access it and pass further.
    Maybe don't think of it as user password, it can be crypted plaintext.



  • 6.  Re: PS: Storing a password

    Posted Feb 24, 2016 10:33 AM

    Here's what we need to understand as basics.

     

    • CA SSO does not perform writes into Identity Store OOB for Identity Store User Attributes.
    • CA SSO only writes into Identity Store in Attributes which are CA SSO proprietary & are created for CA SSO features e.g.
      • Password Policy (SM_DISABLED, PASSWORD_DATA).
      • UCG
      • APS
    • UserPassword updates requests are initiated by CA SSO, however the actual write is performed by Identity Store.
      • The Identity Store controls the encryption & storing. Not CA SSO.

     

    Circling back to your thought about "May be don't think of it as userPassword, it can be crypted plaintext".

     

    In this case CA SSO won't update this attribute (neither clear text nor crypted). So you need something in the background which speak directly to Identity Store and manages / populates / updates this Attribute. CA SSO can read this attribute if granted access and pass it as a header. Before the Identity Store passes the value to CA SSO, Identity Store can decrypt and make available for CA SSO as a clear text.

     

    Bottemline is you need to work with CA SSO Experts & Identity Store Experts to decide which component should have the ownership of encrypting and decrypting the attribute. I would ideally handle this outside CA SSO and let CA SSO only deal with the responsibility of reading an attribute & returning as header. I would ideally let Identity Store handle the encryption-decryption / updation of the attribute.

     

     

    Regards

     

    Hubert