I would like to implement an architecture based on oAuth2 in which the token is generated by the WSO2 identity server (Auth Server) and the API manager is used as the Gateway (resource server).
I understood it's necessary to change the Identity_Server/repository/conf/carbon.xml and set the value false for the element <HideAdminServiceWSDLs>false</HideAdminServiceWSDLs> in order to enable the admin Service of token validation exposed by the Identity Server. Also I think it's necessary to configure the APIManager.xml to configure the API manager to check the token validation using a service exposed by the identity server.
But unfortunately the specific documentation is not available at https://docs.wso2.org/display/AM140/Configuring+api-manager.xm. Can someone help me understand how to achieve my goal ?
If it's correct to assume what you want is to, secure a exposed rest API with OAuth, using WSO2 IS, then the following link [1] will help you.
But since you are using WSO2 API manager, if there is no other restriction you can simply achieve this token generation functionality from API-manager itself. There is an OathTokenEndPoint exposed by API-M. You can call this endpoint with client-key and secret to get a token.[2]
[1] - http://movingaheadblog.blogspot.com/2014/02/securing-your-web-service-with-oauth2.html
[2] - https://docs.wso2.org/display/IS410/OAuth+2.0+Grant+Types+with+WSO2+API+Manager+Authorization+Code
Related
I am wondering about one aspect of Identity Server that I hope to use in my projects.
The scenario is relatively simple:
I have an API and a couple of clients
I want to protect that API using Identity Server and OIDC
On one client, I was looking at the concept of having optional authentication.
Some features would require certain claims i.e Admin
The Rest should allow anonymous users access, but should only allow requests from the registered clients
This should also be reflected on the API
The caveat here is I would like still restrict the API to only be accessed by the registered clients in Identity Server only
Is this scenario possible in Identity Server?
I understand I would set up the Admin Policy on the API but do I also have to set up a CORS feature as well or does Identity Server do this out fo the box using the Allowed scopes and Resources Configuration?
Apologies if the explanation is poor I will try and add a diagram soon
Yes, if you wish to restrict API access to authenticated requests only, one way is via scope validation by setting up a global authorization policy (see https://github.com/IdentityServer/IdentityServer4.AccessTokenValidation).
Your admin endpoints would check for an additional claim. There are several ways to do this, one way is policy based authorization (https://learn.microsoft.com/en-us/aspnet/core/security/authorization/policies?view=aspnetcore-2.2).
You will need to configure the CORS middleware for your API (see https://learn.microsoft.com/en-us/aspnet/core/security/cors?view=aspnetcore-2.2). If you need CORs access to the Identity Server endpoints, then you'll need to configure Identity Server (see http://docs.identityserver.io/en/latest/topics/cors.html).
My question is rather large as I didn't know exactly what to ask, if you have a more specific title don't hesitate to edit.
I'm currently working on a poc where the scenario is the following :
the end user (bob) wants to access some application (randomApp)
randomApp calls our apim which will first check that the randomApp is registered onto the store with an access token and has access to the API
then pass it to the identity server (IS) which will check with the inbound authentication component with for example openID Connect that the randomApp is registered as a service provider and that OAuth key & secret match
this randomApp has some federated authentication declared in the local & outbound auth component to redirect it to an openID Connect (OIC) server where bob will actually authenticate to access the ressource
the OIC server is declared as an identity provider with some credentials from the OIC server, all the URL from the OIC server are declared auth, token and callback endpoint.
bob authenticate correctly, the info is then passed back to the IS which give it to the SP who can finally call the API and display bob's information.
Is this scenario conceivable ? I'm having a hard time grasping every single interaction between all the components. Let me know if some steps are not necessary, overkill or else. I've been playing around with the playground from wso2 but I'm not sure that it depicts exactly the scenario I want.
To summarize : end user -> service provider -> wso2 identity server -> OIC server and go back the other way. What would be the best "setup" for this ?
I hope the article use-cases-of-utilizing-saml-with-wso2-api-manager will be useful for your requirement. In this article, the flows are explained with SAML protocol. You can use the same functionality with OIDC as well.
We are currently analyzing the API gateway for our microservices and Kong is one of the possible candidate. We discovered that Kong support several plugins for authentication but the all based on users stored in Kong database itself. We need to delegate this responsibility to our custom auth HTTP service and don't want to add these users in API gateway database.
It's possible to do this with some code around, instead of using the OpenID connect plugin; in effect you need to implement an Authorization Server which talks to Kong via the Admin (8001) port and authorizes the use of an API with externally given User Ids.
In short, it goes as follows (here for the Authorization Code grant):
Instead of asking Kong directly for tokens, hit the Authorization Server with a request to get a token for a specific API (either hard coded or parameterized, depending on what you need), and include the client ID of the application which needs access in the call (you implement the /authorize end point in fact)
The Authorization Server now needs to authenticate with whatever IdP you need, so that you have the authenticated user inside your Authorization Server
Now get the provision code for your API via the Kong Admin API, and hit the /oauth2/authorize end point of your Kong Gateway (port 8443), including the provision key; note that you may need to look up the client secret for the application client id also via the Admin API to make this work
Include client id, client secret, authenticated user id (from your custom IdP) and optinally scope in the POST to /oauth2/authorize; these values will be added to backend calls to your API using the access token the application can now claim using the authorization code
Kong will give you an Authorization Code back, which you pass back to the application via an 302 redirect (you will need to read the OAuth2 spec for this)
The application uses its client and secret, with the authorization code, to get the access token (and refresh token) from Kong's port 8443, URL /oauth2/token.
It sounds more involved than it is in the end. I did this for wicked.haufe.io, which is based on Kong and node.js, and adds an open source developer portal to Kong. There's a lot of code in the following two projects which show what can be done to integrate with any IdP:
https://github.com/apim-haufe-io/wicked.portal-kong-adapter
https://github.com/Haufe-Lexware/wicked.auth-passport
https://github.com/Haufe-Lexware/wicked.auth-saml
We're currently investigating to see whether we can also add a default authorization server to wicked, but right now you'd have to roll/fork your own.
Maybe this helps, Martin
Check out Kong's OpenID Connect plugin getkong.org/plugins/openid-connect-rp - it connects to external identity and auth systems.
I have several web services that I want to make available to clients. My clients are split into two groups:
users using a web browser (I serve a web page that uses javascript + AJAX to request data from the web services)
applications (e.g. server app pulling data into a client's system)
1) I can solve the former by exposing my web services to external users using the application server and I can use the identity server to authenticate access (haven't worked how to do this out yet).
2) The latter is nicely satisfied by using the API manager. I can happily tell clients to log in to the API manager and subscribe to APIs. The APIs I create are proxies for the web services mentioned in 1).
I know that an API I create in the API manager can include a username and password for accessing the proxied web service. Is it possible to let an API proxy a web service that is authenticated using the identity manager? Sorry I'm reading documentation and struggling to understand if I can do this. Thanks
". Is it possible to let an API proxy a web service that is
authenticated using the identity manager? "
Currently APIManager supports the service endpoints which are secured using basicauth/usernametoken.
If you use identityserver to secure you service, using any other mechanism, that wont be supported by APIManager.
Stodge,
Default API manager authentication mechanism is Oauth. it uses Oauth token mechanism to authenticate all APIs.
Please refer [1],
Here the authentication component also sits in the AM. This can be delegated to a different AM instance if required.
Hope this helps.
[1] http://docs.wso2.org/wiki/display/AM140/Token+APIs
I'm evaluating WSO2 Identity Server and WSO2 API Manager.
I registered an API and an application on API Manager. I can call the resources successfully.
I could also add an user into Identity Server and log into that using oAuth authentication.
But, it's not too clear how I can use those two systems together. I would like to use API Manager to expose my API's to some applications. And, I would like to use Identity Server to log the final user. Is that possible? How can I "plug" those two systems?
I am not sure if that's the best way to do that, so, please, advice me.
Thanks
According to my understanding of your use case is you need to expose the API's securely. So you need to used WSO2 Identity Server and WSO2 API Manger. In addition to that you need the best approach for above use case.
With above two product we have below two option.
Configuring WSO2 Identity Server as the Key Manager in WSO2 API
Manager (This link gives a different version combination of both products)
Here we need to add key manger feature to the WSO2 IS.
Configuring the Pre-Packaged Identity Server 5.0.0 with API Manager
1.9.0
In here 1st option have manual configurations. But,2nd option minimized the manual configuration.
The purpose of using the Identity Server is not too clear. Is it to separate the authentication/authorization from the API Manager instance?
By default API Manager is shipped with a Key Management Server component that is responsible for all security and key related operations.This can be configured to authenticate users against a defined user store or multiple user stores. Authorization is based on oAuth 2.0. However, in a production deployment, we recommend that this component is deployed as a separate server instance so that it runs as an external Key Management Server.
This is done by simply using another copy of the API Manager distribution and configuring it as a Key Manager server node.
Hope this helps.
Regards,
Gillian
My understanding is,
if you wanted to use WSO2 API manager (AM) as an API gateway, you don't need a separate IS as AM included an IS engine with security mechanism included such as key manager.
If you need single sign on across all AM components, and you do NOT have other identity provider (IdP), you need a aeparate IS
However, if you do have a separate IdP, you don't need to install an IS server to implement SSO for AM, although the documentation from IS may suggest you do so. For example, a successful SSO implementation has been done with PingFederate/PingIdentity. See How to integrate WSO2 API Manager (AM) 1.10.0 with PingFederate SAML 2.0?