I am using WSO2 Identity Server-5.10.0 and API Manager-3.2.0.
Have created application in devportal and subscribed the APIs to this application.
In Identity server have enabled Role based scope validator for this service provider.
using below API to generate token:
https://IS_host/oauth2/token
After enabling Role based scope validator unable to generate token with scope=apim:subscribe and giving the error invalid scope.
user is assigned with the role -Internal/Subscriber
We are creating Application in Devportal and subscribing APIs to this Application.
We wanted to list the scopes associated with APIs which are subscribed to Particular application. hence we are calling below API to list scopes based on applicationId
https://AM_HOST/api/am/store/v1/applications/{applicationId}
To invoke this API we need to generate Token with scope: apim:subscribe, But after enabling Role based scope validator we are unable to generate token with apim:subscribe.
if we disable Role based scope validator, user will be able to generate token for all the scopes irrespective of roles associated with user.
The apim:subscribe scope is a reserved scope for API Manager REST APIs. Hence, it is not required to create an Application from the Devportal to generate the Tokens with it. You can perform a DCR operation straight to the API Manager to register a client and generate the Access Tokens with the API-M reserved scopes.
Further, I believe that you have configured the IS as the Key Manager by following IS-Connector approach. The Role Based Scope validator feature requires a set of DBs to be shared among the servers.
Hence, the best way to generate the API-M specific scope tokens would be as following
Perform DCR operation to the API Manager instance (not the IS)
This creates a client in the API Manager using the Resident Key Manager of the API Manager and responds back with the consumer credentials (client ID and secret)
Perform Password grant to generate the token using the received consumer credentials
You can learn more on performing the DCR and subsequent calls in Devportal REST API Docs
Hope this helps you to overcome the reported behavior.
Related
I am working on a cloud native microservices based application deployed in AWS. This application should use a OIDC based IdP (preferably AWS Cognito). The authentication and authorization flow are as follows. Once the user logs in using authorization code flow, the IdP generates one ID token and access token. The access token is sent to the backend services for the backend calls. The backend service can fetch the user information through /userinfo endpoint if needed. Additionally, the access token has the required group claim and the scopes to determine if the right access is present.
Now if the backend service needs to call downstream backend internal microservices on behalf of the logged in user, then should I create a
new token with client credentials grant with a reduced scope needed for the service call? or
Should I send the initial access token of the user only?
In the first case the user context is lost in the new access token and if the downstream service requires the user context, then how will the downstream service get the user information?
In the second case the downstream service is not called with the exact specific scope needed for that service and is not security best practice.
However, there is also one more grant call exchange grant (https://www.rfc-editor.org/rfc/rfc8693.html) which supports creating a new access token with the user context from the initial token without relogging in the user (delegation mode in https://www.rfc-editor.org/rfc/rfc8693.html). Is it supported in AWS Cognito? If not, then how can I achieve the same functionality if I use AWS Cognito?
It kind of depends on the level of trust between microservices. By default, if they are part of the same unit, aim for this type of setup:
Orders microservice, requires an orders scope
Shipping microservice, requires a shipping scope
Customer website, uses scopes orders and shipping
You can then flow the user identity securely, if Orders calls Shipping, by forwarding the access token. Meanwhile each API verifies the JWT on every request and checks for the scopes it needs.
Each API should also check for an audience claim has the expected value, representing a set of related APIs, such as api.example.com. I believe currently though, AWS Cognito does not issue an audience claim to access tokens.
If Shipping is a less trusted subdivision of your company, token exchange would be more appropriate. Eg if you have concerns about a Shipping service abusing Orders privileges.
Avoid over-reliance on scopes, or too many of then. Use claims for the main authorization. In Cognito you can look up these values after verifying the JWT but before your API creates its claims principal
Cognito only has quite limited support for more advanced token behaviour, such as issuing custom claims, reference tokens, or token sharing techniques. If you need them, the preferred option is to choose an authorization server that supports the standards.
I'm using WSO2 IS (5.11.0) as the key manager of APIM 4.0.0). I have published a graphql API which is secured by a scope (say 'test_scope' based on a role named 'test'). I have subscribed to the API with the Default Application and have generated the keys as well. When I generate the access token with the scope ('test_scope') and invoke the secured API I'm getting the valid response even though the required role ('test') is not assigned to the user. Below is the curl command which I'm using.
The API Manager will perform the Role-based validation during the token generation. So, if you are generating the JWT Token with a user that has the respective role assigned, then the API Manager will generate the access token with the requested scopes (that are bound to the role).
I believe that you have generated the JWT token using either Client Credentials or Password grant (not able to find the cURL in the question :)), and the token has been generated with a user who has the respective role assigned. To give more clarification, when using the Client Credentials grant, the API Manager will use the Application Owner as the user to verify the Roles and to provide the scopes. Whereas the Password grant, uses the respective username (that is sent), to verify the roles and scopes.
During the runtime, the Gateway will decode the JWT token and verifies whether the required scopes are available. If yes, the Gateway will proceed with the request, and if not it fails.
So to check the process, you can use another user in the same tenant who hasn't been assigned with the specific role and generate the Token with Password grant and invoke the API (in this scenario, the token will be generated with the default scope and not with the mentioned test_scope).
Hope this clarifies and provides a brief understanding of the Token generation and scope validation process.
Basically What I am trying to create is a application will be registered as service provider which has scope(using OIDC dialect) defined in wso2 identity server. So, when user gets access token he will first invoke wso2 API manager which is integrated with wso2 identity server and wso2 API manager will do the assertion once it gets access token by passing to identity server. After the assertion happens in API manager, API manager will pass the access token to the end web-service. The end web-service will use the wso2 identity server OAuth2 SOAP API for assertion of access token along with claims which should be returned. If the token is active then based on the response claim returned by SOAP API end/target web-service will authenticate and allow/deny for the access.
Currently I am getting the access token by implementing custom grant type which sets the access token for indefinite time. While generating access token I am passing username,client key,client secret based on these parameters I am generating access token.
But now I wanted to create a scope which has set of claims(using OIDC dialect) which is mapped to service provider in identity server and also user will be created based on these claims. So, after generating the token which I have done using custom grant type against user, if the user passes the access token for authentication I need to do the custom assertion/validation of token using the claims of user in wso2 identity server.
So, how can I associate scope with service provider/Oauth2 flow. And also how can I do the validation of token along with claims.
I am using OIDC Authentication with WSO2 IS (5.7.0) in an Angular Application, and passing the OAuth2 Access Token (JWT) through to the backend REST APIs for Authentication (Identity Propagation) and Authorization.
I have configured the Service Provider in WSO2 so that the Roles assigned to a User are included in the Groups Claim (groups) in the Access Token (via the oidc Scope), but I'm not sure how I can determine which Permissions the User has inherited from those Roles so that I can apply some coarse-grained Authorization (RBAC) logic within my Angular App / REST APIs. Specifically, I am interested in custom Permissions added to the Service Provider.
I don't particularly want to use WSO2 IS as an XACML PDP for this coarse-grained Authorization at the boundary, but am considering using it for more fine-grained Authorization (ABAC) nearer to data access / manipulation - where we want to take attributes of the data into account. However, I'm not even sure if these Permissions can be used in XACML policies as they are not direct attributes of a User, which is the same reason they are not returned as Claims in an OAuth2 Access Token.
Is there a way to include the inherited Permissions as Claims in the OAuth2 Access Token?
Alternatively, is there a separate WSO2 IS Endpoint I can call with the Access Token to retrieve a list of Permissions - possibly even as Claims returned in a separate Token (JWT)?
From reading the documentation and searching online, there appears to be a complete disconnect between OAuth2 (Scopes/Claims) and RBAC (Roles/Permissions) in WSO2 IS. There's detail on how to Configure Users, Roles and Permissions (RBAC) in WSO2 IS, but nothing on how to then access and use that data to enforce Authorization.
This is possible with an extension.
Check https://github.com/wso2-incubator/samples-is/tree/master/custom-permission-claim-handler out.
I guess this is exactly what you are looking for.
I need to connect to another web application using webservice. That web application uses OAuth protocol to connect to their api. I am new to OAuth, but I did read the documentation :D .
My question is, to connect my web application with their, what data do I need from them?
I basically need to get all data of resource owners.
I think I need:
1) consumer key and consumer secret key from that web application
company
2) token credential from the resource owner
I need this info right?
Can I save the resource owner token credential to get data in the future without resource owner login?
In their web application, it says I can get the following info from them:
OAuth access tokens and secrets - > are these the token credential of
the resource owner?
OAuth Service key and secret -> what are these?
I need this info right?
Yes. You need the resource owner to authorize your application through the OAuth flow. This is signified by token credentials (this used to be called access token).
Can I save the resource owner token credential to get data in the future without resource owner login?
Yes. Token credentials may have limitations on them in regards to expiration time, type of resources you can access etc. But if token credentials are expired (or invalidated by the resource owner him/herself) - your requests will not be accepted and you will have to ask the resource owner for new authorization.
OAuth access tokens and secrets -> are these the token credentials of the resource owner?
Yes. Until recently token credentials were called access tokens in the specification, information about the name changes can be found here: https://www.rfc-editor.org/rfc/rfc5849#section-1.1
OAuth Service key and secret -> what are these?
These are most likely the consumer key and secret.
I followed this Tutorial and it is simple to understand.
Here is the sequence of flow to get it all working.
Get registered on the API Provider (the web application in your case). This will generate client id and client secret for you.
Exchange client id, client secret, end user id/password (in base64 encoded format in http auth header), scope, grant with the API Provider's auth service and get Authorization Code.
Exchange client id, client secret, authorization code with API Provider's token service and get token.
Use this token with other query parameters to proceed with the API requst.
The sequence above is applicable for grant_type=code. If you are going for any other grant type, #2 is not applicable, and in #3, you provide end userid/password to get token directly.