Hi, This random password will only be used to populate the connection password field in the secondary store web ui. This password will be generated when the user presses the edit button and it will be removed when the user completes "update" operation. This password is merely used to populate the connection password field ( Because leaving it blank forces the user to type it each and every time when ever he edits other properties also ).
When the request comes to back end, we remove that random value and store the original password in to config file. @Darshana Since this usage violates the security best practices, shall we restrict the cache invalidation time for an hour ? Regards, Firzhan On Sun, Oct 19, 2014 at 11:14 AM, Afkham Azeez <az...@wso2.com> wrote: > > > On Sun, Oct 19, 2014 at 1:12 AM, Firzhan Naqash <firz...@wso2.com> wrote: > >> >> Hi All, >> >> Let me explain the use case that I am trying to implement. >> >> Currently the secondary user store web ui does not displaying the >> "connection password" property . If a user wanted to edit some properties, >> before updating those properties, user have to type the connection password >> again. >> >> As a solution for this we are trying to generate a random password and >> assign an an unique ID for that password. This unique ID will be associated >> with that particular edit request message for identifying the random >> password. This unique ID should be unique across the cluster. This random >> password will be displayed in the "connection password" field. Therefore >> the editUserStoreConfiguration message will include unique ID + >> properties. >> >> Once user done with updating other properties ( No password change), he >> can send the updateUserStoreConfiguration message. Since the update >> UserStoreConfiguration message has an unique ID, by using that ID we >> can obtain the random password and do a comparison with the password that >> comes with the request. If there are any changes, new password will be >> encrypted and saved with other changes to the secondary store configuration >> file. >> >> In order to support non-sticky session scenarios, we need that particular >> unique ID and random password to be shared across the cluster. Do I have to >> persist this information ? Or is it ok to use javax.cache's expiry time set >> for longer duration ? >> > > You want to maintain this random password indefinitely? Production > clusters could run for years without being shutdown. Even when it comes to > normal passwords, users are required to frequently change it, but you want > to keep a random password forever? That would violate security best > practices. > > >> >> >> Regards, >> Firzhan >> >> On Sat, Oct 18, 2014 at 7:13 PM, Afkham Azeez <az...@wso2.com> wrote: >> >>> If this doesn't get invalidated, why do you need a cache or distributed >>> map? Why not simply store it and load it from registry, and keep it in >>> memory? >>> >>> On Sat, Oct 18, 2014 at 5:42 PM, Johann Nallathamby <joh...@wso2.com> >>> wrote: >>> >>>> >>>> >>>> On Fri, Oct 17, 2014 at 9:52 AM, Darshana Gunawardana < >>>> darsh...@wso2.com> wrote: >>>> >>>>> Hi Azeez, >>>>> >>>>> What it needs here is a distributed map which get synced among nodes >>>>> in the cluster. >>>>> >>>>> 1. What would be the best way to do that? Using a Hazelcast >>>>> distributed map? >>>>> 2. If Hazelcast distributed map is a option, do we have a way to use a >>>>> Hazelcast map when writing a component using 4.2.0 kernel. >>>>> >>>> >>>> I don't see any difference between using javax.cache.Cache and >>>> distributed map except that cache has a timeout. But you can set the >>>> timeout to a large value and that makes it no different to distributed map. >>>> Anyway we can't rely on both of them for HA if entire cluster goes down. In >>>> that case we need to persist. So +1 for javax.cache.Cache. >>>> >>>>> >>>>> Thanks, >>>>> Darshana >>>>> >>>>> On Fri, Oct 17, 2014 at 9:31 AM, Afkham Azeez <az...@wso2.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, Oct 17, 2014 at 12:44 AM, Firzhan Naqash <firz...@wso2.com> >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Are there any specific way to make sure that cache doesn't get >>>>>>> invalidated other than setting a longer duration in the setExpiry() >>>>>>> method >>>>>>> of CacheBuilder ? >>>>>>> >>>>>> >>>>>> No you have to set a large cache expiry time >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Firzhan >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Afkham Azeez* >>>>>> Director of Architecture; WSO2, Inc.; http://wso2.com >>>>>> Member; Apache Software Foundation; http://www.apache.org/ >>>>>> * <http://www.apache.org/>* >>>>>> *email: **az...@wso2.com* <az...@wso2.com> >>>>>> * cell: +94 77 3320919 <%2B94%2077%203320919>blog: * >>>>>> *http://blog.afkham.org* <http://blog.afkham.org> >>>>>> *twitter: **http://twitter.com/afkham_azeez* >>>>>> <http://twitter.com/afkham_azeez> >>>>>> *linked-in: **http://lk.linkedin.com/in/afkhamazeez >>>>>> <http://lk.linkedin.com/in/afkhamazeez>* >>>>>> >>>>>> *Lean . Enterprise . Middleware* >>>>>> >>>>>> _______________________________________________ >>>>>> Dev mailing list >>>>>> Dev@wso2.org >>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Regards, >>>>> >>>>> >>>>> *Darshana Gunawardana*Software Engineer >>>>> WSO2 Inc.; http://wso2.com >>>>> >>>>> *E-mail: darsh...@wso2.com <darsh...@wso2.com>* >>>>> *Mobile: +94718566859 <%2B94718566859>*Lean . Enterprise . Middleware >>>>> >>>>> _______________________________________________ >>>>> Dev mailing list >>>>> Dev@wso2.org >>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>> >>>>> >>>> >>>> >>>> -- >>>> Thanks & Regards, >>>> >>>> *Johann Dilantha Nallathamby* >>>> Associate Technical Lead & Product Lead of WSO2 Identity Server >>>> Integration Technologies Team >>>> WSO2, Inc. >>>> lean.enterprise.middleware >>>> >>>> Mobile - *+94777776950* >>>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* >>>> >>> >>> >>> >>> -- >>> *Afkham Azeez* >>> Director of Architecture; WSO2, Inc.; http://wso2.com >>> Member; Apache Software Foundation; http://www.apache.org/ >>> * <http://www.apache.org/>* >>> *email: **az...@wso2.com* <az...@wso2.com> >>> * cell: +94 77 3320919 <%2B94%2077%203320919>blog: * >>> *http://blog.afkham.org* <http://blog.afkham.org> >>> *twitter: **http://twitter.com/afkham_azeez* >>> <http://twitter.com/afkham_azeez> >>> *linked-in: **http://lk.linkedin.com/in/afkhamazeez >>> <http://lk.linkedin.com/in/afkhamazeez>* >>> >>> *Lean . Enterprise . Middleware* >>> >>> _______________________________________________ >>> Dev mailing list >>> Dev@wso2.org >>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>> >>> >> > > > -- > *Afkham Azeez* > Director of Architecture; WSO2, Inc.; http://wso2.com > Member; Apache Software Foundation; http://www.apache.org/ > * <http://www.apache.org/>* > *email: **az...@wso2.com* <az...@wso2.com> > * cell: +94 77 3320919 <%2B94%2077%203320919>blog: * > *http://blog.afkham.org* <http://blog.afkham.org> > *twitter: **http://twitter.com/afkham_azeez* > <http://twitter.com/afkham_azeez> > *linked-in: **http://lk.linkedin.com/in/afkhamazeez > <http://lk.linkedin.com/in/afkhamazeez>* > > *Lean . Enterprise . Middleware* >
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
