Hi all, Now that the magic user is gone, what can we do to communicate between these servers. I had an offline chat with Prabath and the idea is to setup mutual auth for each of the following cases.
"Carbon to Carbon" - Mutual auth "Carbon to Jenkins" - If Jenkins can handle mutual auth modify our jenkins authenticator plugin to handle it and remove the jenkins user that we use now. First cut may go with the known jenkins user "Jenkins to Carbon" - We are using axis2 client so we can talk to a mutual auth enabled Carbon server "Carbon to GitBlit" - Check if GitBlit support mutual auth and modify our Gitblit authenticator plugin to handle it and remove the known user. First cut may go with known user "GitBlit to Jenkins" - If 2 is done then we can get this easily thanks, dimuthu On Wed, Jul 17, 2013 at 2:14 PM, Prabath Siriwardena <[email protected]>wrote: > Had a brief chat with Dimuthu and I guess it's much cleaner to get rid of > the magic user - with the introduction of organization concept in AF. > > The admin user account of the tenant it self can perform these > operations... > > If we think about a multi-VPC deployment (a VPC per tenant) - we do not > want to keep super tenant user credentials in each VPC. > > Thanks & regards, > -Prabath > > > On Wed, Jul 17, 2013 at 9:15 AM, Dimuthu Leelarathne <[email protected]>wrote: > >> >> >> >> On Wed, Jul 17, 2013 at 9:06 AM, Shiroshica Kulatilake <[email protected]>wrote: >> >>> Hi, >>> >>> Instead of using a different type of user for each type of operation >>> wouldn't it make sense to use the super tenant to do all administration >>> activities. Or would this cause problem for some type of activities ? >>> >> >> We are talking about the magic user in the system - not the super tenant. >> This magic user exit in all tenants - not only in super tenant. Since we >> already have a SSO cookie in hand my argument is rather than doing another >> login why not used the same cookie? Clearly either we don't need SSO or we >> don't need the magic user. Doesn't make sense to have both. >> >> Using the same user for other things is a deployment option. >> >> thanks, >> dimuthu >> >> >> >>> >>> Hoping to use the super tenant user to do all BAM related things which >>> is keeping in par with what SLive is doing right now. >>> >>> Thank you, >>> Shiro >>> >>> >>> On Wed, Jul 17, 2013 at 8:36 AM, Dimuthu Leelarathne >>> <[email protected]>wrote: >>> >>>> >>>> >>>> >>>> On Wed, Jul 17, 2013 at 6:32 AM, Samisa Abeysinghe <[email protected]>wrote: >>>> >>>>> All actions done for a tenant, better be done the super tenant of that >>>>> user. Clean ins't it? >>>>> >>>>> >>>> There are several things to address here. The magic user is used for 3 >>>> things mainly. (There could be other minor things) >>>> >>>> 1) Magic user credentials in super tenant mode is used to call admin >>>> services in the platform >>>> >>>> Yes we can use the magic user of that tenant to call admin services. >>>> But we already have a session Id returned by SSO for a specific user. It >>>> makes sense to use that session Id straight away rather than using magic >>>> user in the same domain. Right now we maintain one single BE cookie, but >>>> since we already have a authenticated session I think it is worth a try to >>>> use it. >>>> >>>> 2) System update rxts >>>> >>>> Right now the rxts are in super tenant space and we used the magic user >>>> in super tenant mode to do the update. But in future we can use the magic >>>> domain user, but if we don't have a magic user we can do start tenant flow >>>> and go ahead with it. >>>> >>>> 3) Checks out code to jenkins to trigger builds >>>> >>>> This could be a complete separate user. >>>> >>>> The magic user is not required it seems. So why do we need to keep him? >>>> >>>> thanks, >>>> dimuthu >>>> >>>> >>>> >>>> >>>>> On Wed, Jul 17, 2013 at 5:44 AM, Dimuthu Leelarathne < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> AF has a magic user that exist in all tenants. This magic user is >>>>>> used in following scenarios. >>>>>> >>>>>> - appmgt jaggery app use it to authorize/authenticate to Admin >>>>>> services >>>>>> - Jenkins use it to run system builds >>>>>> - Update rxts in registry >>>>>> >>>>>> With the introduction of multi tenancy concept it would make all >>>>>> sense to remove this magic user due to following scenarios. >>>>>> >>>>>> - To utilize the platform level tenant lazy loading concepts >>>>>> - To use our Admin services as it is and the best example >>>>>> ApplicationMgtAdmin service >>>>>> >>>>>> In short to be MT truly this user has to go away. >>>>>> >>>>>> So we will manage the existing scenarios as follows. >>>>>> - To trigger system driven auto builds we will use a user specific to >>>>>> gitblit and Jenkins >>>>>> - Updating rxts can be done as a super tenant then within that we >>>>>> will start tenant flows when updating rxts >>>>>> >>>>>> WDYT? >>>>>> >>>>>> thanks, >>>>>> dimuthu >>>>>> >>>>>> -- >>>>>> Dimuthu Leelarathne >>>>>> Architect & Product Lead of App Factory >>>>>> >>>>>> WSO2, Inc. (http://wso2.com) >>>>>> email: [email protected] >>>>>> Mobile : 0773661935 >>>>>> >>>>>> Lean . Enterprise . Middleware >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Thanks, >>>>> Samisa... >>>>> >>>>> Samisa Abeysinghe >>>>> VP Engineering >>>>> WSO2 Inc. >>>>> http://wso2.com >>>>> http://wso2.org >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Dimuthu Leelarathne >>>> Architect & Product Lead of App Factory >>>> >>>> WSO2, Inc. (http://wso2.com) >>>> email: [email protected] >>>> Mobile : 0773661935 >>>> >>>> Lean . Enterprise . Middleware >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Shiroshica Kulatilake >>> >>> Architect, >>> WSO2, Inc. http://wso2.com/ >>> Phone: +94 776523867 >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Dimuthu Leelarathne >> Architect & Product Lead of App Factory >> >> WSO2, Inc. (http://wso2.com) >> email: [email protected] >> Mobile : 0773661935 >> >> Lean . Enterprise . Middleware >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Thanks & Regards, > Prabath > > Mobile : +94 71 809 6732 > > http://blog.facilelogin.com > http://RampartFAQ.com > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Dimuthu Leelarathne Architect & Product Lead of App Factory WSO2, Inc. (http://wso2.com) email: [email protected] Mobile : 0773661935 Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
