Not directly relate to $subject, but we have seen following use cases when customers have third party IdPs.
1. Configure Store/Publisher to SSO directly with third party IdP using SAML SSO (without using WSO2 IS) 2. Configure Store/Publisher to SSO directly with third party IdP using OIDC (without using WSO2 IS) In APIM-2.x.x versions, we can do the above two use cases either with JIT provisioning the user to APIM or sharing the same user store between third party IdP and APIM. Reference [1]. Does APIM-3.x.x also support for both of the use cases mentioned above ? [1]. https://dzone.com/articles/sso-wso2-api-manager-amp-keycloak Regards, Dinusha On Tue, Jan 7, 2020 at 6:15 PM Malintha Amarasinghe <malint...@wso2.com> wrote: > Hi, > > On Tue, Jan 7, 2020 at 3:20 PM Ishara Cooray <isha...@wso2.com> wrote: > >> Hi, >> >> In addition to the above, >> if we want to enable customer url per tenant we need to add callback URLs >> of each tenant in the service provider config. >> Which seems to be not scalable. >> >> This can be mitigated to some extent by creating SPs per tenant. >> Any thoughts? >> > Can we identify which SP to use when redirecting to /authorize endpoint as > we get to know the tenant name later on during login. > > Thanks. > >> >> Thanks & Regards, >> Ishara Cooray >> Associate Technical Lead >> Mobile : +9477 262 9512 >> WSO2, Inc. | http://wso2.com/ >> Lean . Enterprise . Middleware >> >> >> On Tue, Jan 7, 2020 at 12:32 PM Harsha Kumara <hars...@wso2.com> wrote: >> >>> >>> >>> On Tue, Jan 7, 2020 at 12:27 PM Malintha Amarasinghe <malint...@wso2.com> >>> wrote: >>> >>>> >>>> >>>> On Tue, Jan 7, 2020 at 12:23 PM Harsha Kumara <hars...@wso2.com> wrote: >>>> >>>>> >>>>> >>>>> On Tue, Jan 7, 2020 at 12:20 PM Malintha Amarasinghe < >>>>> malint...@wso2.com> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Currently, we do not support $subject and we always use the local IDP >>>>>> as the login/logout URLs (/authorize and /oidc/logout). In normal cases, >>>>>> this works without issues. But when it comes to configuring federated >>>>>> login >>>>>> with facebook, google etc, it is required to use IS (IS as KM) as the >>>>>> intermediate IDP which has the required authenticators to support >>>>>> facebook/google logins. In those cases, we need to point the local IDP to >>>>>> the IS/KM and the IS/KM points to Facebook as a federated login. But this >>>>>> flow has unnecessary one additional hop caused by the local IDP. >>>>>> >>>>>> As a solution, we plan to support externalizing the IDP URL (used for >>>>>> /authorize and /oidc/logout). >>>>>> >>>>>> [image: image.png] >>>>>> >>>>>> The plan is to introduce new configs as below: >>>>>> >>>>>> *api-manager.xml* >>>>>> >>>>>> {% if apim.idp is defined %} >>>>>> <IdentityProvider> >>>>>> <!-- Server URL of the Identity Provider used for login/logout >>>>>> operations in API Publisher and API Developer Portal --> >>>>>> >>>>>> <AuthorizeEndpoint>{{apim.idp.authorize_endpoint}}</AuthorizeEndpoint> >>>>>> >>>>>> <OIDCLogoutEndpoint>{{apim.idp.oidc_logout_endpoint}}</OIDCLogoutEndpoint> >>>>>> >>>>>> </IdentityProvider> >>>>>> {% endif %} >>>>>> >>>>>> *deployment.toml* >>>>>> >>>>>> #[api.idp] >>>>>> #authorize_endpoint = "https://localhost:9444/oauth2/authorize"; >>>>>> #oidc_logout_endpoint = "https://localhost:9444/oidc/logout"; >>>>>> >>>>> Token endpoint will be pointed to gateway? >>>>> >>>> >>>> No, it will still use the local endpoints eg; >>>> https://localhost:9443/oauth2/token. All the backend calls (generate >>>> token, DCR, refresh token) will use the local hardcoded endpoints in 9443 >>>> port. >>>> Hope that would not cause an issue? >>>> >>> Yes that should be fine. Since we do share databases in this scenario, >>> it should be fine to go with the local endpoints. >>> >>>> >>>> Thanks! >>>> >>>>> >>>>>> By default, the server will use the local IDP for login/logout. Only, >>>>>> if the above URLs are configured, they will be used instead of the >>>>>> default >>>>>> ones. >>>>>> >>>>>> Thoughts are highly appreciated. >>>>>> >>>>>> Thanks! >>>>>> Malintha >>>>>> >>>>>> -- >>>>>> Malintha Amarasinghe >>>>>> *WSO2, Inc. - lean | enterprise | middleware* >>>>>> http://wso2.com/ >>>>>> >>>>>> Mobile : +94 712383306 >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *Harsha Kumara* >>>>> >>>>> Technical Lead, WSO2 Inc. >>>>> Mobile: +94775505618 >>>>> Email: hars...@wso2.coim >>>>> Blog: harshcreationz.blogspot.com >>>>> >>>>> GET INTEGRATION AGILE >>>>> Integration Agility for Digitally Driven Business >>>>> >>>> >>>> >>>> -- >>>> Malintha Amarasinghe >>>> *WSO2, Inc. - lean | enterprise | middleware* >>>> http://wso2.com/ >>>> >>>> Mobile : +94 712383306 >>>> >>> >>> >>> -- >>> >>> *Harsha Kumara* >>> >>> Technical Lead, WSO2 Inc. >>> Mobile: +94775505618 >>> Email: hars...@wso2.coim >>> Blog: harshcreationz.blogspot.com >>> >>> GET INTEGRATION AGILE >>> Integration Agility for Digitally Driven Business >>> >> > > -- > Malintha Amarasinghe > *WSO2, Inc. - lean | enterprise | middleware* > http://wso2.com/ > > Mobile : +94 712383306 > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > -- Dinusha Dilrukshi Senior Technical Lead WSO2 Inc.: http://wso2.com/ Mobile: +94764069991 Blog: http://dinushasblog.blogspot.com/
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
