Hi Ratha,
On Fri, Jul 26, 2013 at 6:32 PM, Vijayaratha Vijayasingam <[email protected]>wrote: > > > On 26 July 2013 17:50, Rajeev Sampath <[email protected]> wrote: > >> Hi Prabath, >> >> >> On Fri, Jul 26, 2013 at 3:35 PM, Prabath Siriwardena <[email protected]>wrote: >> >>> >>> >>> On Fri, Jul 26, 2013 at 3:24 PM, Prabath Siriwardena >>> <[email protected]>wrote: >>> >>>> There three aspects.. >>>> >>>> 1. Protect the confidentiality of the token at rest (in storage) >>>> 2. Protect the confidentiality of the token in transit. >>>> 3. Protect the confidentiality of the token from the client. >>>> >>>> [2] is achieved through TLS. >>>> >>>> [3] this is the one which mentioned in the spec. This is needed if we >>>> have to include certain information in to the token that should not be >>>> visible to the client. >>>> >>>> Doing [3] is very costly. What client gets there is an encrypted token. >>>> So - its the same encrypted token that it will send to access resources. So >>>> - for each request we need to decrypt it. >>>> >>>> Also the issue in [3] is - if you store the encrypted token in the >>>> database - somebody having access to the database - can take the encrypted >>>> token and use it to access the API (he does not need to decrypt it). >>>> >>>> What I would suggest is this. >>>> >>>> In the access token we issues we have some information parts and a >>>> secret part. >>>> >>>> Information part is something like domain name.. like wise. Secret part >>>> is the randomly generated string. >>>> >>>> Access Token = INFORMATION_PART + SECRET_KEY >>>> >>>> This is what I suggest.. >>>> >>>> Access Token = Base64Encode(INFORMATION_PART + ":" + SECRET_KEY) >>>> >>>> Client will get the Access Token and we store *Hash(SECRET_KEY)* in >>>> the database (no encryption) >>>> >>> >>> >>> Correction --> we store *Hash(Access Token)* >>> >>> >>>> >>>> Now - when accessing the API client will send the Access Token >>>> >>>> Decoded Access Token = Base64Decode(Access Token) >>>> = INFORMATION_PART + ":" + >>>> SECRET_KEY >>>> >>>> Now to validate the token we check, *Hash(SECRET_KEY{from request}) = * >>>> *Hashed Secret Key from database* >>>> >>> >>> Correction --> *Hash(Access Token{from request}) = **Hashed Access >>> Token from database* >>> * >>> * >>> >> >> In addition to these at IS level, access tokens are stored in AM as well. >> So IMO for those, we'll have to use a symmetric algorithm that can also >> decrypt and get the original key from an encrypted key. >> >> > Why do we need decryption if we use hashing? And where will we need the > original key, if we issue the encoded token to client? > > >> >> My concern was on a scenario where AM having to use a stored token in non hashed form (such as sending it to OAuth). In that case, OAuth will be expecting an encoded but not hashed key (which I referred to as original key here). So if the keys can't be converted back to the original state at AM level won't that be a problem? Or else won't there be such scenarios? Thanks Rajeev > Thanks >> Rajeev >> >> >> >>> ** >>> Thanks & regards, >>> -Prabath >>> * >>> * >>> >>>> >>>> This way we do not want to worry about encryption - and we also do not >>>> store access token in clear text in the database. >>>> >>>> Refresh token can be just stored as a hash. >>>> >>>> Thanks & regards, >>>> -Prabath >>>> >>>> On Fri, Jul 26, 2013 at 2:59 PM, Sumedha Rubasinghe >>>> <[email protected]>wrote: >>>> >>>>> We need to attend to $subject. >>>>> >>>>> OAuth2 spec also recommends this in it's Threat Mitigation section. >>>>> >>>>> http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-16#section-4.2 >>>>> "For those cases where the client is prevented from observing the >>>>> contents of the token, token encryption MUST be applied in addition to the >>>>> usage of TLS protection." >>>>> >>>>> Some design considerations. >>>>> 1. Should be configurable (default off), configured via identity.xml >>>>> 2. Need to consider token validation flow as well (hash should be >>>>> generated of incoming token & compared) >>>>> 3. Should we also store encrypting algorithm as well? (for backward >>>>> compatibility if it changes after sometime) - Is this a real scenario? >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> /sumedha >>>>> b : bit.ly/sumedha >>>>> >>>> >>>> >>>> >>>> -- >>>> Thanks & Regards, >>>> Prabath >>>> >>>> Mobile : +94 71 809 6732 >>>> >>>> http://blog.facilelogin.com >>>> http://RampartFAQ.com >>>> >>> >>> >>> >>> -- >>> Thanks & Regards, >>> Prabath >>> >>> Mobile : +94 71 809 6732 >>> >>> http://blog.facilelogin.com >>> http://RampartFAQ.com >>> >> >> >> >> -- >> Rajeev Sampath >> Senior Software Engineer >> WSO2, Inc.; http://www.wso2.com. >> >> Mobile:* +94716265766 >> * >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > -Ratha > mobile: (+94)755906608 > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Rajeev Sampath Senior Software Engineer WSO2, Inc.; http://www.wso2.com. Mobile:* +94716265766 *
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
