I thought twice about this .. I doubt whether we should put a higher priority task like this in to GSoc which simply affect our road map. I have a feeling we need to come up with some ideas which are more of like tools and nice to have features for Airavata. Major development task like this would affect the road map and current implementation.
WDYT ? Lahiru On Mon, Feb 20, 2012 at 7:11 PM, Suresh Marru <[email protected]> wrote: > Hi Lahiru, > > Sorry I did not read your approach in detail to comment on it yet, but I > have some overarching thoughts. agree this is a missed need for Airavata. I > can think of lot more use cases beyond what you list here. Can we make this > is a GSOC project? I do not mean to stop you if you are volunteering to > jump into it right now, but may be we can get whats needed for now and also > make a GSOC project for a comprehensive solution? > > Also, any thoughts on to leverage Sling here? > http://sling.apache.org/site/managing-users-and-groups-jackrabbitusermanager.html > > Suresh > > On Feb 20, 2012, at 3:23 PM, Lahiru Gunathilake wrote: > > > Hi Devs, > > > > Before we go in to production with Airavata, we need to finish the user > > management support with reasonably good features. Currently we do not > allow > > to create new users in the system since Jackrabbit doesn't support users > > when we access Jackrabbit in RMI mode. I prefer implementing our own user > > management on top of Jackrabbit so that we have our control over it. I am > > suggesting an approach of implementing user management with following > > structure. > > > > 1. During the gateway deployment we deploy Jackrabbit with hidden user > name > > password which is not accessible for XBaya users or GFac Users. > > > > 2. When the real user (XBaya user) want to registry there is a user > > management Service hosted for each Gateway so that users can register > them > > selves with their credentials. When user register them we create a top > > level node for that users and store their credentials on that top leve > > node. (During the storing of the credentials we do not have to store in > > them in plain text, Gateway deployer can implement a handler to encrypt > the > > password before storing/retrieving the password.. so this implementation > > can be deployment specific, for the time being we can implement a sample > > handler for this). So when we store Inputs/Outputs and all the provenance > > data we store under the root level user node (Currently we store under > root > > node). > > > > 3. There is another Service which is secured from end users but allowed > to > > access only for Gateway admin who can manage users with basic user > > management features. > > > > 4. During the descriptor registration users can make them public.. if > they > > make them public we do not store those information under users root node > > but we put them in to Public Node. During xbaya loading we pull the users > > specific descriptors and public descriptors. That public Node can be > > accessed only if user provide user specific public credentials. > > > > WDYT ? > > > > Lahiru > > -- > > System Analyst Programmer > > PTI Lab > > Indiana University > > > -----BEGIN PGP SIGNATURE----- > > iQIcBAEBAgAGBQJPQuFPAAoJEHmz9P1hfdutxn0P/AzaeX6K0bGaj08hmixjUaH7 > VUrHQQg1+dIJxNlF3XLkvlaRLdhqFlPCo9FQYOwWWQ28ye7yWAv0gWNOa1iI9sK/ > gUGHIu3p9JvAXts82MEA2XGQztzIlGkVgIBC7uuRNG7nZZsNgFlSqKyEhAOOnpw6 > /hViQ3IeCZhLWVtTfBH1fMpxzxdtjc2kVeGoLih1t+Fy77MbkMnqbGjovl2Q7+wF > 7kMUEpWeT6lS9MrB8XqNpJpwcyux1WfUvxFnqmMYD77Tw5VVGKKpODb9cd4l7uZU > /NLGR78yEoZxKp21arcBTHf1QOE62tt//Jc8qD2J36agLu+ZO2N2AzbOnkdhSLqV > 4bTHyCcT1SRCONRkvcR51IJMlTRs3Z9N9wJtLTzktV+WNFzCAcm5CouSc3xjO3w7 > 0lEGrIEUQurY+7/5ejkKz4cngvfiVk5Qeo4dO6JgVmrVVft45a6WTLOSGEB5Du09 > dgBwvpdS3ow5ABW5XPbEX+/Ybn3rcmMucfgWCwGwpTWRp2oAXeH/sDYZM+DyhjyK > JmQnGsujwMACSHekZlUONODaDjf+Cve3p1MAaG/R4NPiEzjOf926n8BuJdVgzIdX > gKYcd2cVCPcjU35CGHx2fQrPZVB/dq5+fekf8LZPKuMw3hi9wLjfuVYRWQC7ZwfZ > DK33opugphcvsRKa0we3 > =BnKk > -----END PGP SIGNATURE----- > > -- System Analyst Programmer PTI Lab Indiana University
