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