I still don't get what is an admin API vs non-admin API. Taking BPS as an example,
- Let's assume a client is writing a process-triggering app using the provided APIs. - They want to complete a user task by sending few users to be used as candidate users in the next step. - For this they need both user API and process API. It's just an example, but from the user's perspective, both are same level APIs in this case. In this case listing users is not an admin task. In current method, at some layer we have *hard-code* admin credentials and call list user AIPs using that. Maybe a better solution is to use two (or n?) *scopes*, and let the scopes be configurable as needed. On Fri, May 6, 2016 at 4:59 AM, Afkham Azeez <[email protected]> wrote: > There is a way to do this. At the point of deploying the service, you have > to specify on which transports that service is exposed. This is similar to > the concept of exposing services on selected transports in Axis2. > > On Fri, May 6, 2016 at 2:26 PM, Sagara Gunathunga <[email protected]> wrote: > >> >> >> On Thu, May 5, 2016 at 2:32 PM, Kishanthan Thangarajah < >> [email protected]> wrote: >> >>> Another thing is, should we also work on exposing admin services on one >>> listener (probably over https) and other user api's on different listener? >>> May be we need to bring in some changes to MSF4J core to support this via >>> OSGi level service properties and listener id's. >>> >> >> Usually it uses separate port for admin services so that that port can be >> protected with high level of security, +1 explore this option. >> >> Thanks ! >> >>> >>> >>> On Thu, May 5, 2016 at 7:39 AM, Afkham Azeez <[email protected]> wrote: >>> >>>> Will you run admin stuff & user stuff on the same instances? At least >>>> shouldn't our recommendation be that admin & user stuff have to be >>>> separate, as a best practice? >>>> >>>> On Wed, May 4, 2016 at 9:12 PM, Hasitha Aravinda <[email protected]> >>>> wrote: >>>> >>>>> Hi Manu, >>>>> >>>>> In my point of view, we have to decide it based on what API does and >>>>> who are the actual users involve. >>>>> >>>>> In BPS, we have two sets of users: workflow participants and admin >>>>> user/devOps of the BPS. Based on these users we can categorized BPS APIs >>>>> into two sets. >>>>> >>>>> - Admin APIs : There are few APIs like artifact deployer API, >>>>> accessed only by administrators of the server or devOps. >>>>> >>>>> >>>>> - User APIs : BPMN Rest API and HumanTask API are user APIs, >>>>> because these APIs only accessed by participants of processes and user >>>>> tasks. But we can argue some of the operations are admin operations, >>>>> but >>>>> those are business admin operations. These resources/operations need to >>>>> be authorized using an ACL, based on current user and his role in >>>>> workflow >>>>> or user-task. >>>>> >>>>> For example in HumanTask [1], we have several roles i.e. Business >>>>> Administrator, Potential Owners, Excluded Owners, Stakeholders etc. Based >>>>> on current user and his role in defined task, user are authorized to >>>>> perform an operation. >>>>> >>>>> IMO having clear separations between User API and Admin API may >>>>> important when securing these APIs separately. >>>>> >>>>> [1] - >>>>> http://docs.oasis-open.org/bpel4people/ws-humantask-1.1-spec-cs-01.html#_Toc261430341 >>>>> >>>>> Thanks, >>>>> Hasitha. >>>>> >>>>> On Wed, May 4, 2016 at 7:55 PM, Manuranga Perera <[email protected]> >>>>> wrote: >>>>> >>>>>> How do we define an admin vs non-admin API? >>>>>> Is getting list of users different from getting the list of processes? >>>>>> >>>>>> A customer written UI may have to call both. We can argue that some >>>>>> things are 100% admin eg: shutdown server. But to me this seems like an >>>>>> arbitrary decision. >>>>>> >>>>>> >>>>>> On Wed, May 4, 2016 at 12:14 AM, Hasitha Aravinda <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Another thing, we need to consider exposing different ports for user >>>>>>> APIs and Admin APIs to have a clear separation. In C4 all user and admin >>>>>>> APIs exposed in 9443 and 9763. AFAIK this is not supported in current >>>>>>> MSF4J >>>>>>> OSGi version. >>>>>>> >>>>>>> Thanks, >>>>>>> Hasitha. >>>>>>> >>>>>>> On Wed, May 4, 2016 at 9:26 AM, Nandika Jayawardana < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hi All, >>>>>>>> >>>>>>>> In all the carbon platform versions up to now, we used 9443, and >>>>>>>> 9763 ports for admin services for all server products. Are we going to >>>>>>>> use >>>>>>>> the same ports for C5. >>>>>>>> >>>>>>>> Regards >>>>>>>> Nandika >>>>>>>> >>>>>>>> -- >>>>>>>> Nandika Jayawardana >>>>>>>> WSO2 Inc ; http://wso2.com >>>>>>>> lean.enterprise.middleware >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Architecture mailing list >>>>>>>> [email protected] >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> -- >>>>>>> Hasitha Aravinda, >>>>>>> Senior Software Engineer, >>>>>>> WSO2 Inc. >>>>>>> Email: [email protected] >>>>>>> Mobile : +94 718 210 200 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> With regards, >>>>>> *Manu*ranga Perera. >>>>>> >>>>>> phone : 071 7 70 20 50 >>>>>> mail : [email protected] >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> -- >>>>> Hasitha Aravinda, >>>>> Senior Software Engineer, >>>>> WSO2 Inc. >>>>> Email: [email protected] >>>>> Mobile : +94 718 210 200 >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> *Afkham Azeez* >>>> Director of Architecture; WSO2, Inc.; http://wso2.com >>>> Member; Apache Software Foundation; http://www.apache.org/ >>>> * <http://www.apache.org/>* >>>> *email: **[email protected]* <[email protected]> >>>> * 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* >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> *Kishanthan Thangarajah* >>> Associate Technical Lead, >>> Platform Technologies Team, >>> WSO2, Inc. >>> lean.enterprise.middleware >>> >>> Mobile - +94773426635 >>> Blog - *http://kishanthan.wordpress.com >>> <http://kishanthan.wordpress.com>* >>> Twitter - *http://twitter.com/kishanthan >>> <http://twitter.com/kishanthan>* >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Sagara Gunathunga >> >> Architect; WSO2, Inc.; http://wso2.com >> V.P Apache Web Services; http://ws.apache.org/ >> Linkedin; http://www.linkedin.com/in/ssagara >> Blog ; http://ssagara.blogspot.com >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > *Afkham Azeez* > Director of Architecture; WSO2, Inc.; http://wso2.com > Member; Apache Software Foundation; http://www.apache.org/ > * <http://www.apache.org/>* > *email: **[email protected]* <[email protected]> > * 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* > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- With regards, *Manu*ranga Perera. phone : 071 7 70 20 50 mail : [email protected]
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
