I am managing my APIs using WSO2 API Mananger.Till now every API were private and can be accessed using an access token.
The new use cases some API's which is purely public. Any one can access them anonymously. Just a GET,POST,PUT wihtout any token/access details should work.
I exposed API's via WSO2 API Manager without any scopes. Tried to access them without any token ;but its not working.It says required oAuth credentails not found.
Is there anything else to do to expose APIs so that they are accessible anonymously?
In the Manage page of publisher, you can set Authentication Type to None for each resource instead of the default value Application and Application User.
Related
We are using WSO2IS as IAM server , roles and Users are managed in WSO2IS. WSO2EI WILL be integration server , exposing private APIs
What would be the right way to implement role based access control using , like some set of APIs only to be accessed by users with specific groups. How can I implement this most simplest way ? Is there a requirement of WSO2AM here ?
Thanks
EI is not the ideal way to exposing private oauth secured APIs. Even though you can achieve it with EI, that would be an excessive effort when integrating.
Use API Manager to expose the APIs to your crowd. Configure Identity Server as the Key Manager (Token Manager) of the APIM server. APIM server knows how to talk to the Identity Server to generate and validate access tokens. So there's no explicit effort to integrate the resource server(APIM Gateway) with the authorization server(IAM).
Share the user store between both the servers. (IS and APIM)
Configure IS as the Key Manager of the API server.
Register your API in the publisher/developer portal.
When publishing, you can define role based access restrictions to your API resources from the Publisher portal. (Roe : Scope mapping)
Once you define, IS will always check your roles upon providing an access token for you.
As you've already defined a role : scope mapping, scopes you request in your token generation request, will only be accepted if you (requester) has the expected roles. Therefore, the scope of your token will only be as good as the roles you've got assigned to yourself. Now, as the API resources you've published require a defined set of scopes, not all the access tokens will be accepted when trying to access the APIs. Only the ones with the expected scopes.
Configure IS-KM with APIM
Role based scopes
I'm having separate Dotnet Web Service API to authenticate users. How can I configure it with WSO2 API Manager?
I have already configured WSO2 API Manager with external IDP (Keycloak). Is this is what im looking orcan be achieved in different way.
If you are looking for a way to replace your user store(LDAP/AD/JDBC), with your Dotnet service, you might want to write a new custom user store manager extending the CarbonRemoteUserStoreManger class. There, you should invoke your custom APIs to authenticate, retrieve users. Then you can add a secondary/primary user store with your custom user store manager implementation.
If you want to configure your Dotnet service as a Federated IdP in the API Manager server, you might have to write a Custom Federated Authenticator to communicate with your Dotnet service to authenticate the users. There you should be overriding the initiateAuthenticationRequest and processAuthenticationResponse.
Editing the answer with the new context on issue
In order to generate or validate tokens with an external party(Dotnet service), WSO2 needs to know the service contract of that service beforehand. How you fetch that information to the WSO2 APIM server is by writing an extension to the Key Manger service of the WSO2 APIM server.
By default WSO2 APIM has the implementation to talk to its own Key Manager component and the WSO2 Identity Server. But you need to write the logic (request/response templates) to validate tokens with your dotnet service. This is the official documentation for this. These two Medium posts as well are written on that topic.
Blog 1
Blog 2
Basically, you need to write a simple java extension project to the mentioned interface, so that WSO2 knows how to talk to your service. A sample such implementation written for Okta as a Key Manager is pointed here.
Regarding your concern on validating both the token types;
Yes, it's possible using a custom key manager interface as described above. Once you receive the token at the API Manager side, if you can distinguish if the token was issued by your Dotnet service or by WSO2 itself from your Java logic (May be the token length), then your logic should divert the validation request respectively to WSO2 default Key Validation service (Call super()) or to your Dotnet service call. If you can't distinguish between the two tokens just by looking at them, then you can try both the servers to check if either can validate it. (There's a security vulnerability in that.)
Hope this helps.
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?
Firebase Rest API mentions that we can pass CREDENTIAL to provide access to authenticated nodes. However I was not able to find documentation on where I can find these credential or generate these credential. Custom tokens generated using NodeJS firebase-admin client also don't work.
https://firebase.google.com/docs/database/rest/save-data
https://docs-examples.firebaseio.com/rest/saving-data/auth-example.json?auth=CREDENTIAL
If you scrolled down a little on the same page, you would find the answer:
In the following example we send a POST request with an auth parameter, where CREDENTIAL is either our Firebase app secret or an authentication token...
Firebase secrets are legacy credentials you can find/create under Project settings - Service Accounts in the Console. Using one as the auth parameter gives the caller administrative access.
Or you can use a service account to generate admin level access tokens instead of relying on the legacy secrets. See here for the Java implementation.
Or if you have an authenticated user – for example you're implementing an API a client apps call via HTTP, passing along their current access token –, you can use that token directly to impersonate the user.
The custom authentication tokens serve a completely different purpose and are part of a different sign in flow. Therefore they do nothing via the REST API.
How can I pass the access token created on an OpenIdConnect Federated IDP to the developer application?
Currently, the federated access token doesn't get passed through the API Manager and the API Manager generates a new access token for the application.
You won't be able to plug in an external IDP and generate access tokens using an out-of-the-box API Manager. But you can implement a custom keymanager implementation and plug external third party keymanager to API manager and then use that tokens. See Configuring a Third-Party Key Manager in the product documentation regarding this. It has a sample where "Surf OAuth Authorization Server" is use as the key manager. You will be able to implement similar thing for your scenario.
following are some good posts related to this feature.
https://amilasnotes.wordpress.com/2015/06/20/customizing-key-validation-flow/
https://amilasnotes.wordpress.com/2015/05/19/integrating-with-a-third-party-oauth-provider-overview/
https://amilasnotes.wordpress.com/2015/06/07/provisioning-oauth-clients-created-out-of-band/