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
