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.
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 want to user Google Identity Platform as the CIAM solution for our GKE-based cloud service. We have a requirement to allow 3rd parties to access our cloud APIs using credentials they obtain via OAuth.
For example, our cloud service provides APIs that Google Assistant or Amazon Alexa can access on behalf of our users. Therefore, we want to provide an OAuth-based token manager that uses the identities of our customers as defined in the Google Identity Platform.
Is this type of OAuth service possible using Google Identity Platform, or the underlying Firebase service that drives it?
Based on the documentation for Google Assistant, you will need to implement your own OAuth2 endpoints. In the authorization code flow, you need two endpoints:
The authentication endpoint needs to sign in the user and get their permission to allow the third party (eg. Google) to call the customer's API on their behalf. If the user gives permission then they return an authorization code - which could be implemented by creating a custom token with Cloud Identity Platform.
Token exchange endpoint is also needed, which has two functions. The first is to exchange the authorization code created by the first endpoint for a refresh token and an ID token. The second is to exchange a refresh token for a new ID token. Both of these functions can be delegated to Cloud Identity Platform.
Additional note:
I would suggest to use custom claims to ensure that these tokens can only be used for the intended purposes, ie. to perform actions which the Google Assistant needs to do. Users shouldn't be allowed to perform other actions, eg. changing the user's password or providing authorization codes to other third parties.
Also make sure that this endpoint can't be used by malicious third parties. For example, you can check that the redirect URL provided matches what is expected, since this is where the authorization code will be sent to.
I have an app and openid identity server. My app retrieves tokens from the Identity server.
I have also configured the identity server as an external provider for an AWS Cognito Identity Pool.
I can successfully retrieve AWS credentials for the User logged into my app.
However, I find the AWS credentials limited as the token does not contain any of the claims from the original login token. Is there any way to get them in there?
One the claims I use is clientID and I was hoping to be able to use that in a an IAM Policy to restrict S3 access by client.
I haven't found direct solution for that, and it seems like missing feature.
The workaround I did was:
Mapping id_token/access_token/refresh_token to custom cognito attributes. As all mapped attributes are later available in your frontend, you need to restrict read permissions for sensitive attributes.
Use TokenGeneration_HostedAuth lambda trigger to work on this data.
I have created and published API with WSO2 API Manager. API client get access through OAuth2 and client credentials grant, sending consumer key and consumer secret to request access token. But now I need to implement authorization by means of authorization code grant. I have to use client_id and client_secret of WSO2 APIM and user login form of my backend application, not WSO2 APIM user.
Can anybody tell if it is possible and how it can be implemented???
Documentation of WSO2 does not describe this flow and all examples I have found describe authorization process (OAuth2, authorization_code) only for user of WSO2 APIM.
now I need to implement authorization by means of authorization code grant.
I have to use client_id and client_secret of WSO2 APIM and user login form of my backend application, not WSO2 APIM user.
If you want to use your own (application) authentication form, the simplest option is to leverage the password grant type where your application sends the token request along application and user credentials through a backend service
Using a code grant you suppose to use an authorization endpoint https://gateway:8243/authorize with parameters described in the documentation and indeed the default login form is used when the user is not yet authenticated
(I still have an urge to downvote the question for not searching the documentation)
If you still want to use the code grant type with your own authentication form, you may either customize the default logon form of the wso2 api gateway or customize an authenticator to use form of your application (this is quite advanced topic requiring configuring your own implementation and out of scope of the question/answer)
You have 2 options here without any customizations.
1) If your backend has a userstore, it can be configured as a secondary userstore for APIM. Then you can use any user in that userstore for authentication.
See https://docs.wso2.com/display/ADMIN44x/Configuring+Secondary+User+Stores
2) If above option is not possible, and if your backend IDP supports any federation SSO protocols such as SAML2 or OIDC, you can configure federation using WSO2 IS.
See https://docs.wso2.com/display/IS550/Single+Sign-On+and+Identity+Federation
I'm confused about how end user authentication works with WSO2 AM.
It looks like by default, WSO2 AM acts as the user authentication server for OAuth flows and hence validates user credentials against those entered via the API Store and stored in the Key Manager. But those users are not end users of the destination APIs, but rather developers who've signed up to build apps to use the APIs. That doesn't make sense to me, so maybe I've misunderstood the documentation?
What I need and would think most other API publishers would need is the ability to authenticate end users against an API publisher's user authentication API, and so have WSO2 AM delegate user authentication to such an external authentication API via a redirect (in case of authorization grant or implicit grant flows) or server-server call (in case of resource owner credentials grant).
How would one go about configuring such a setup, and what's the interface between the WSO2 AM and the external authentication API, for both the redirect and server-server interactions? Can you point me to any documentation or samples of such a setup?
thx,
Chris
My perspective on this is that end users consume apps directly, not APIs. App developers build apps that consume APIs. So this conforms to philosophy of WSO2 API Manager, where it is catering to the app developers.
An API publisher's user authentication API is just another API as far as the API Manager is concerned. You can expose this API through API Manager and have users(or apps in my opinion) invoke the API with specified parameters and get a response(In your case user credentials as parameters and a response based on the authentication of those credentials). What an underlying API does is of no concern to API Manager, it simply facilitates the management of the API invocation.
Often apps make authenticated user-specific requests to APIs to service users using the apps. The OAuth2 resource owner password credentials grant is one of a few OAuth grant options used by apps to obtain user-specific OAuth tokens, and it requires authenticating the user's credentials against the API publisher's user authentication API. For reference, here's apigee's documentation on how to do it.
wso2 APIM has four role models-> admin,creator,publisher and subscriber.
so those who have creator and publisher role can create and publish an api in publisher app(they are developers).
and those who have subscriber role can subscribe to api in store and generate the oath token(they are end users).So whenever a user singup from store will be assigned to subscriber role. so those who have only subscription role are endusers of that api.
so when an end user access the api using the token taken from store, he will be authenticated by APIM.
1.https://docs.wso2.com/display/AM160/User+Roles+in+the+API+Manager