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* <http://wso2.com/>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
