Hi, On Mon, Jul 29, 2013 at 11:31 PM, Rajeev Sampath <[email protected]> wrote:
> Hi Prabath, > > In addition to these tokens, AM has application tokens which are handled > in a separate path. Unlike access tokens, they need to decryptable to > original format since they need to be shown in a UI to the user. > Here what Rajeev mentioned is the generation and showing of 'Application Access Tokens' from APIStore UI. If we are going to hash the Application Tokens stored in database with each token generation time,then there will be an issue on showing the *original* application access token back from UI in each web page refresh time as we are directly querying the token from database..So we may need to keep a two way encryption mechanism for 'application access tokens'. > > What would be the best way to handle application tokens in this case? Is > it okay to use one way hashing for access/refresh tokens and a two way > encryption algorithm here for application tokens? > Thanks; > > > Thanks > Rajeev > > > On Fri, Jul 26, 2013 at 7:07 PM, Prabath Siriwardena <[email protected]>wrote: > >> AFAIK tokens are stored only in one place.. >> >> Thanks & regards, >> -Prabath >> >> >> On Fri, Jul 26, 2013 at 7:01 PM, Rajeev Sampath <[email protected]> wrote: >> >>> 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 >>> * >>> >> >> >> >> -- >> 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 > * > -- Lalaji Sureshika WSO2, Inc.; http://wso2.com/ email: [email protected]; cell: +94 71 608 6811 blog: http://lalajisureshika.blogspot.com
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
