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 ?
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
