I have deployed wso2am-4.0.0(a.com), I configure keycloak as key manager and IDP, everything works fine. But there is a scenario that i don't know how to achive.
[1] A third party(B.com) wants to synchronize the WSO2 API.
[2] B.com wants to invode api which are fetched from a.com.
[3] A.com and B.com both integrate keycloak.
[4] Keycloak acts as a unified user management, Authorization Management and Authentication Management are both in keycloak.
Like this:
B.com will get apis by uri https://a.com:9443/api/am/publisher/v2/apis, which provides all apis in wso2,
B.com gets swagger by uri https://a.com:9443/apis/{{apiId}}/swagger, for the swagger has api definition witch third party can invode, like curl http://gateway:8243/hello/v1/name=simon.
The problem is, access_token are required in both [1] and [2] , where the token fetch from?
And, if b.com also register a client in keycloak, is the token valid to access a.com' api?
Anyone know other solutions for this problem?
Related
I am calling a third party API which needs authorization header with Basic base64 encoded (for the third party API). I also have to do proxy authentication with my company's proxy server with Basic authentication (with service account with AD authentication).
The issue I am facing when I send both of the properties proxy forward the request with the service account to the API not the Authorization header. Has anyone else faced similar issues. Please advise.
A Django site acts as an oauth2 provider. A setup for an app tomcat_app looks like:
Whenever somebody tries to login into tomcat_app a user will get redirected to Django. If the user can provide valid credentials they will get redirected to tomcat_app. So far so good. Tomcat_app further offers a REST API which is aware of the oauth2 workflow. If the reqeust supplies a valid token requests will get accepted.
The knot in my head: A third server should be granted to use the tomcat_app rest api as well. Is it possible to
setup a new user in django externalapp_user/externalapp_password
obtaining a key for tomcat_app by sending the new users credentials to django
Where I'm puzzled is, is how to correctly send the credentials and how to deal with the redirect url. I'm looking for something similar to client type: public and Authorization grant type: Resource ownder password-based
curl -X POST -d "grant_type=password&username=admin&password=admin" http://client:secret#localhost/o/token/
What I understand from the django-oauth-toolkit documentation is that: If you want to use 'Resource owner password-based' Authorization grant type you need to have the user registered on your tomcat_app.
But if you don't want to have the user registered on your app and still provide him with the api endpoint, It is better to use 'Client credentials' Authorization grant type. This will give the third party app the ability to access your api endpoints after they login their users.
You can check out the documentation for better understanding the 'Client credential' flow.
We have written our custom spring API to hit the WSO2 API manager for user authorization and getting the JWT token.Along with this login API,we have also configured all our other spring APIs through the API manager.To hit the /token endpoint before accessing our APIs, we need to give a list of all the scopes which have been created in the API publisher. Right now this list of Scopes has been hard coded from the front end/our UI to hit the APIs.
Is there a way to get this list of scopes directly from WSO2 without hard coding it in the front end while hitting the /token endpoint?
I successfully configured WSO2 API Manager 1.8.0 [e.g. https://wso2am.com:9443] and WSO2 Identity Server 5.0.0 SP1 [IS] acting as Key Manager [e.g. https://wso2is.com:9443] in a clustered setup on 2 different servers.
I also configured a Service Provider in the IS using a SAML SSO Inbound Authenticator and tested it with travelocity.com sample app.
The sample app builds the SAML request in the right way, but https://wso2am.com:9443/samlsso?SAMLRequest=[base64stuff] returns an HTTP Status 405 - HTTP method GET is not supported by this URL.
Changing the url in https://wso2is.com:9443/samlsso?SAMLRequest=[base64stuff]
leads to successful authentication.
Basically I want to be redirected to wso2am login page and not wso2is login page.
In this way, I could deploy in DMZ WSO2AM only, leaving WSOIS in the internal network.
How can I do?
Thanks
In this scenario I think your authentication request must be directed to IS server, not APIM. The IS server is the one who does the authentication. Hence it acts as the IDP. APIM is just a service provider (SP). Even if you succeeded (even it's not the correct behaviour) with sending a SAML request to https://wso2am.com:9443/samlsso endpoint, it will redirect you to the login page in IS server. So you have to send the SAML request to the https://wso2is.com:9443/samlsso endpoint for successful authentication & for the correct behavior.
I have an admin-console for an existing service that I want to provide access to by adding login, using our company's OAuth 2.0 service. I want to use Apigee here, so that the web-app with the admin-console does not have to implement the login-logic.
My idea was to use AuthorizationCode flow and let Apigee manage the tokens and I looked into https://github.com/apigee/api-platform-samples/tree/master/sample-proxies/oauth-login-app, but I really can't see how our existing OAuth service fits in.
Is there a sample like that? Perhaps using Google's or Facebook's OAuth service to authenticate the user?
First, Apigee needs to be a proxy into the admin-console. This means that all traffic to the admin-console has to go through Apigee. Otherwise, you won't be able to enforce authentication.
Second, there are a couple different options for integrating with the external oauth 2.0 service. Apigee has the ability to store an external access token and use it as its own, or Apigee can generate a token and store the external access token as a custom attribute.
High level thoughts on how the Apigee proxy could look like:
ProxyEndpoint - endpoint exposed to clients connecting to admin console
TargetEndpoint (not shown in that oauth login-app example) - endpoint for the actual admin console
The flows that execute in the Apigee proxy before sending the request to admin-console will need to implement logic that checks an authentication token. If it's valid, let the request pass onto the TargetEndpoint (admin-console). If the request isn't valid, step through logic that goes calls the external oauth 2.0 server's auth code flow. This will require the following:
Apigee needs to be registered with external oauth 2.0 server.
Logic needs to be built in this proxy to support the redirection based flow of authorization code grant_type (obtaining auth code, receiving the auth code, obtaining token --> all while being redirection based and transparent to user).
In addition to #2, Apigee will need to store the external token as custom attribute and expose the apigee token, or store the external token for verification purposes later on. http://apigee.com/docs/api-services/content/authorize-requests-using-oauth-20 (see Delegating token management). After the token is stored, you'd need to respond with another 302 redirect to the initial uri + token so the request can pass through to admin-console as an authenticated request.
#2 isn't exactly straight-forward and there won't be an example proxy that shows this implementation. If the oauth 2.0 service supported a password grant, it may simplify the implementation, but allows the credentials to pass through apigee and not directly with the authorization server.