Hi Pubudu, In above diagram,both the gateway types are pointing to same keymanager.,Have we considered the scenario of having different keymanagers per each gateway node.For example,multiple DC deployment[master-slave] scenario..Then how we will extend the UI experience in Store side?
Thanks; On Tue, Feb 7, 2017 at 10:28 PM, Roshan Wijesena <[email protected]> wrote: > Label approach is much more cleaner for me then API publisher can decide > where that API should go. > > Question :- How publisher and gateways both sync with label names? when an > API came with an unknown label what will happen. We should have predefined > label set right? > > On Wed, Feb 8, 2017 at 11:45 AM, Isuru Haththotuwa <[email protected]> > wrote: > >> Hi, >> >> On Wed, Feb 8, 2017 at 11:37 AM, Shani Ranasinghe <[email protected]> wrote: >> >>> Hi, >>> Can't we use the existing roles to do this? Restricted by roles? >>> >>> for e.g API A (public) has a role "public" and API B(internal) has a >>> role "internal" . We develop our API admin portal to let the gateway know >>> which roles to look for. So from our admin portal we say internal gateway >>> will allow API's with role "internal", and public gateway will allow API's >>> with role "public". Then when the request hits the gateway, it will check >>> if the requested API has invokers roles associated with the API. Would this >>> not work? >>> >> Technically can do. But AFAIU there is a security aspect of separating >> the gateway as internal and external. The internal gateway would not be >> exposed to the same network as the public/external one. Hence there might >> be use cases where we can't use a single gateway for both internal and >> external. >> >>> >>> On Wed, Feb 8, 2017 at 10:04 AM, Abimaran Kugathasan <[email protected]> >>> wrote: >>> >>>> HI Pubudu, >>>> >>>> 1. Who will be responsible for creating these labels? I guess, it >>>> should be created from Admin Portal and those labels should be propagated >>>> to store, publisher, gateway. >>>> >>>> 2. How do you restrict the users invoking from different gateway >>>> environments? Allowing to invoke from provided gateway environment. We >>>> can't validate from Key Manager since Key Manager can be anything which >>>> adheres OAuth 2 spec. They don't need to know anything related labels. >>>> >>>> 3. How do you map users to labels? Who will map the users? If an admin >>>> does this, on which basis labels will be assigned to users? >>>> >>>> 4. We can't let the users create label because it reflects the internal >>>> gateway deployment pattern. >>>> >>>> >>>> On Wed, Feb 8, 2017 at 5:03 AM, Ishara Cooray <[email protected]> wrote: >>>> >>>>> Hi Pubudu, >>>>> >>>>> What will be the behavior when an api is updated >>>>> >>>>> 1. From API publisher UI >>>>> 2. From the api artifact itself(if it is allowed). >>>>> >>>>> >>>>> Thanks & Regards, >>>>> Ishara Cooray >>>>> Senior Software Engineer >>>>> Mobile : +9477 262 9512 <+94%2077%20262%209512> >>>>> WSO2, Inc. | http://wso2.com/ >>>>> Lean . Enterprise . Middleware >>>>> >>>>> On Tue, Feb 7, 2017 at 10:49 PM, Nuwan Dias <[email protected]> wrote: >>>>> >>>>>> Hi Matteo, >>>>>> >>>>>> To give you some context, this model is suggested for API Manager >>>>>> version 3.0.0 which will be on a new Carbon platform version, version 5. >>>>>> Its literarily a rewrite of the current API Manager product and hence >>>>>> we're >>>>>> rethinking and redesigning all features. >>>>>> >>>>>> What we're trying to achieve here is to give the ability for APIs to >>>>>> be deployed in separate zones. i.e. Internally accessible vs publicly >>>>>> accessible. How we supported this earlier was by making the API Publisher >>>>>> push APIs to Gateways in different zones when the APIs were being >>>>>> published. But deploying APIs in the API Publishing process had its own >>>>>> set >>>>>> of problems such as >>>>>> >>>>>> 1. When it was required to publish to many Gateway, the publishing >>>>>> process consumed a lot of time. >>>>>> 2. If the API deployment failed partially, we had to record the >>>>>> failures while still changing the state of the API. The API publishers >>>>>> had >>>>>> to later republish. >>>>>> 3. If a new zone is added later, the API publishers had to republish >>>>>> the APIs to the new zone. >>>>>> >>>>>> Most of these problems stemmed from the fact that we were using a >>>>>> "Push" model of APIs instead of a "Pull". The model suggested for API >>>>>> Manager 3.0.0 is a "Pull" model by which we try to achieve a lot of >>>>>> dynamicity and make the API Publishing process more robust at the same >>>>>> time. >>>>>> >>>>>> Thanks, >>>>>> NuwanD. >>>>>> >>>>>> On Tue, Feb 7, 2017 at 9:53 PM, Matteo Bordin < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hello >>>>>>> why does not it be possible to use the feature “Environment”? >>>>>>> I mean the configuration into the api-manager.xml file >>>>>>> “<APIGateway> >>>>>>> <!-- The environments to which an API will be published --> >>>>>>> <Environments> >>>>>>> <!-- Environments can be of different types. Allowed >>>>>>> values are 'hybrid', 'production' and 'sandbox'. >>>>>>> An API deployed on a 'production' type gateway will >>>>>>> only support production keys >>>>>>> An API deployed on a 'sandbox' type gateway will >>>>>>> only support sandbox keys >>>>>>> An API deployed on a 'hybrid' type gateway will >>>>>>> support both production and sandbox keys. --> >>>>>>> <!-- api-console element specifies whether the >>>>>>> environment should be listed in API Console or not --> >>>>>>> <Environment type="hybrid" api-console="true"> >>>>>>> <Name>Production and Sandbox</Name> >>>>>>> <Description>This is a hybrid gateway that handles >>>>>>> both production and sandbox token traffic.</Description> >>>>>>> <!-- Server URL of the API gateway --> >>>>>>> <ServerURL>https://localhost:$ >>>>>>> {mgt.transport.https.port}${carbon.context}services/</ServerURL> >>>>>>> <!-- Admin username for the API gateway. --> >>>>>>> <Username>${admin.username}</Username> >>>>>>> <!-- Admin password for the API gateway.--> >>>>>>> <Password>${admin.password}</Password> >>>>>>> <!-- Endpoint URLs for the APIs hosted in this API >>>>>>> gateway.--> >>>>>>> <GatewayEndpoint>http://${carb >>>>>>> on.local.ip}:${http.nio.port},https://${carbon.local.ip}:${h >>>>>>> ttps.nio.port}</GatewayEndpoint> >>>>>>> </Environment> >>>>>>> </Environments> >>>>>>> </APIGateway> “ >>>>>>> >>>>>>> So we create more than one environment, one for each “label”, the >>>>>>> configuration could be: one api gateway manager for environment and any >>>>>>> number of gateway for manager. >>>>>>> When you deploy the API you can decide where you would like to >>>>>>> deploy your API, the publisher using the admin service publish the API >>>>>>> into >>>>>>> the correct gateway, in the store you can see the url of the gateway >>>>>>> where >>>>>>> you have deployed the API. >>>>>>> Probably I don not understand the requirements. >>>>>>> Could you provide us a real use case? >>>>>>> This is my two cents! >>>>>>> >>>>>>> bye >>>>>>> Matteo >>>>>>> >>>>>>> >>>>>>> Matteo Bordin >>>>>>> Profesia s.r.l. - http://www.profesia.it >>>>>>> via Po, 1 - 10124 Torino (TO) Tel +39 011 0120371 >>>>>>> <+39%20011%20012%200371> Fax +39 011 3710371 >>>>>>> <+39%20011%20371%200371> >>>>>>> Piazzale Luigi Sturzo, 15 - 00144 Roma Tel +39 06 87811323 >>>>>>> <+39%2006%208781%201323> >>>>>>> Cell: +39 346 017 91 68 >>>>>>> Skype: matteobordin >>>>>>> eMail: [email protected] >>>>>>> — >>>>>>> “Profesia, innovation in action" >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 7 Feb 2017, at 15:01, Pubudu Gunatilaka <[email protected]> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> There can be situations where we need to host public gateways for >>>>>>> public traffic as well as private gateways for internal traffic. In >>>>>>> general, there can be different gateway environments which serve >>>>>>> particular >>>>>>> APIs. The publisher can decide which API should be served by which >>>>>>> gateway >>>>>>> environment. >>>>>>> >>>>>>> The flow is as follows. >>>>>>> >>>>>>> <Labels based GWs.jpg> >>>>>>> >>>>>>> >>>>>>> 1. When creating an API, the publisher can decide the labels for an >>>>>>> API. Labels can be public, private, etc. Users can define labels based >>>>>>> on >>>>>>> their use cases. Once the API is published, an event is published to >>>>>>> the >>>>>>> topic. >>>>>>> 2. Gateways are subscribed to the particular topics at the startup >>>>>>> and they will receive the API publishing event. Gateways are capable of >>>>>>> loading APIs on demand as well as able to load when API is published. >>>>>>> Gateways should be started with a label. For an example, the public >>>>>>> gateway >>>>>>> should be started providing an argument at startup with label value >>>>>>> public. >>>>>>> This is to identify the environment. >>>>>>> 3. When requesting a particular API from the publisher, the gateway >>>>>>> should provide the label value. The publisher will check the available >>>>>>> labels in the API and the gateway only receives the API only if there >>>>>>> is a >>>>>>> match for the given label in the API. >>>>>>> 4. Key validation. >>>>>>> >>>>>>> In Store, there will be a REST API to get the label information >>>>>>> which contains the label name and the URL of the gateway. This is used >>>>>>> to >>>>>>> display the gateway URLs in the API store. By default, it will display >>>>>>> all >>>>>>> the available environments. There is an extension point which users can >>>>>>> use >>>>>>> to restrict showing particular gateway endpoints based on the user who >>>>>>> logs >>>>>>> into the API store. >>>>>>> >>>>>>> *Note: *These gateway environments are not same as having Dev , QA >>>>>>> and Prod environments of the API Manager deployment. Dev, QA, Prod >>>>>>> environments are called stages in API Manager from C5 onwards. In a >>>>>>> particular stage, there can be different gateway environments. >>>>>>> >>>>>>> Please share your thoughts. >>>>>>> >>>>>>> Thank you! >>>>>>> -- >>>>>>> *Pubudu Gunatilaka* >>>>>>> Committer and PMC Member - Apache Stratos >>>>>>> Software Engineer >>>>>>> WSO2, Inc.: http://wso2.com >>>>>>> mobile : +94774078049 <%2B94772207163> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Nuwan Dias >>>>>> >>>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>>> email : [email protected] >>>>>> Phone : +94 777 775 729 <+94%2077%20777%205729> >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Thanks >>>> Abimaran Kugathasan >>>> Senior Software Engineer - API Technologies >>>> >>>> Email : [email protected] >>>> Mobile : +94 773922820 <+94%2077%20392%202820> >>>> >>>> <http://stackoverflow.com/users/515034> >>>> <http://lk.linkedin.com/in/abimaran> >>>> <http://www.lkabimaran.blogspot.com/> <https://github.com/abimarank> >>>> <https://twitter.com/abimaran> >>>> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Thanks and Regards >>> *,Shani Ranasinghe* >>> Senior Software Engineer >>> WSO2 Inc.; http://wso2.com >>> lean.enterprise.middleware >>> >>> mobile: +94 77 2273555 <077%20227%203555> >>> Blog: http://waysandmeans.blogspot.com/ >>> linked in: lk.linkedin.com/pub/shani-ranasinghe/34/111/ab >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Thanks and Regards, >> >> Isuru H. >> +94 716 358 048 <+94%2071%20635%208048>* <http://wso2.com/>* >> >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Roshan Wijesena. > Senior Software Engineer-WSO2 Inc. > Mobile: *+94719154640 <+94%2071%20915%204640>* > Email: [email protected] > *WSO2, Inc. :** wso2.com <http://wso2.com/>* > lean.enterprise.middleware. > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Lalaji Sureshika WSO2, Inc.; http://wso2.com/ email: [email protected]; cell: +94 71 608 6811 blog: http://lalajisureshika.blogspot.com
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
