I have an AuthorizationHandler that evaluates some authorization requirements for policy-based authorization. Some part of ASP.NET Core calls HandleRequirementAsync with an instance of AuthorizationHandlerContext.
Where does AuthorizationHandlerContext.User get populated?
For context, I look up some properties in AuthorizationContext.User that correspond to OAuth2 claims in a JWT access token that is included in the HTTP request. This is working fine when the JWT token was issued by IdentityServer4, but now I am adding support for access tokens to come from a secondary Identity Provider.
When the token is from this other provider, AuthorizationContext.User is a null object containing all-blank fields (i.e. it has none of the claims that are in the access token). This secondary identity provider (and its public key) are included in the JWT Bearer authentication scheme in TokenValidationParameters.ValidIssuers and TokenValidationParameters.IssuerSigningKeys, respectively.
This leads to the following log messages:
AuthenticationScheme: "Bearer" was successfully authenticated.
Authorization failed for user: <sub from the access token used in the request>
Related
In my application, there is a part where cookie authentication takes place and some apis that relies on jwt. So I am using two schemes (Cookie & JWT). Asp.net Identity handles the cookie authentication and a custom api handles jwt. Both of these methods call a common method to create the claims.
So what happense is now cookie has X no. of claims and the JWT token also have the same number of claims.
But at any given point in time when I check the Principal.Identity.Claims, it has duplicates (from Cookies & JWT).
I am sure this happense by some middleware in which it collects claims from cookie & jwt and then prepare the principal for the request.
Is there a way to avoid this duplication? May be write my own middleware? If so what should I override in the pipeline?
we plan to introduce an API management solution and we're currently setting up a proof of concept with WSO2 AM. We want to use the WSO2 API gateway to check whether a certain consumer application is allowed to use an API and to throttle the request rate.
I work on the identity workflow and I wonder how a consuming application can pass a JWT token to the backend service with WSO2-AM in between.
First, this is our current scenario:
Without API gateway
The consuming application gets a JWT token for its carbon user from an identity provider. The JWT contains some claims about the user, e.g. the roles he/she belongs to.
The app calls the service an passes the JWT token in the Authorization HTTP header like: Authorization: Bearer
The service validates the issuer and signature of the JWT and retrieves the claims from it.
So, this is pretty straight forward. Now we put an API gateway in between the application and the service:
With API gateway
The consuming application gets a JWT token for its carbon user from an identity provider.
The consuming application uses OAuth2 to get an access token for the following API calls. We can use the client_credentials grant type and simply pass the the client id and client secret. I haven't yet tried it, but we could possibly use the JWT grant type (see https://docs.wso2.com/display/ISCONNECTORS/Configuring+JWT+Grant+Type) and use the JWT for passing user information to the API gateway.
The API gateway validates the JWT against the public key of the identity provider when using the JWT grant type.
An access token is returned to the app.
The app sends an API request to the gateway and passes the access token in the Authorization HTTP header.
The gateway validates the access token.
The gateway forwards the API request to the service.
And there is my problem: How can the JWT from 1/2. be passed to the service?
There is a documentation for "Passing Enduser Attributes to the Backend Using JWT" (see https://docs.wso2.com/display/AM210/Passing+Enduser+Attributes+to+the+Backend+Using+JWT), but this would introduce a new JWT, issued and signed by WSO2-AM, and I'm not sure, whether this JWT contains all information from the JWT used to create the access token (or even the original JWT).
Another way I could think of is using a custom HTTP header for passing the JWT through the gateway to the service. I cannot use the Authorization header (as we do without the API gateway), because WSO2-AM expects the access token in that header.
Since I'm not happy with either solutions, I want to ask the experts: How would you solve this?
Thanks,
Torsten
The only possibility I can think of is to send the JWT token in a custom Header for the backend service.
We are current building a collection of back-end ASP.NET Core microservices. These services will not be accessed directly from the front-end application, but rather accessed through an ASP.NET Core API gateway. We are using IdentityServer4 for the OpenID Connect server. I have been able to setup the UseJwtBearerAuthentication middleware to have API gateway validate the JWT bearer token (access_token) against IdentityServer4. I would like to be able to have the API gateway inject the id_token, based on the access_token, into the requests made to the back-end services that may need to know the end-user.
Is there a way to configure the JWT middleware to retrieve the id_token when validation the access_token or do I need to manually call the OpenID Connect server in the API gateway?
You don't use id_tokens at APIs - they are for clients.
If you want to have access to certain identity claims, either include them in the access token (by configuring the ScopeClaims on the resource scope), or use the access token to contact the userinfo endoint which in turn will return the identity claims.
The JWT middleware performs standalone verification, it does not contact the identity server to verify or retrieve anything. You'll have to make an additional call.
I created asp.net web api project. I need to add authorization or/and authentication. I've read a lot about OAuth, SAML, JWT, HMAC etc. and everytime I see author emphasizes that OAuth is not authentication and you need to differ authN from authZ. I'm a bit confusing because I don't understand:
when I need to use authentication (SSO, login/password) and when authorization(OAuth, tokens) for API?
are HMAC, JWT for authorization or for authentication? because they are signed and I can add userid to this token use like user identifier
what are real differences between authN workflow and authZ workflow?
OAuth can be also used to authenticate users using a resource owner grant (i.e. a client gets an access token providing an user+password credential).
The resulting access token is what you should call authorization, since it will contain info like claims describing permissions, permission masks or roles (it depends on what authorization scheme you implement in your solution).
A JWT (JSON Web Token) is just a JSON representation of both access token and any other associated info. JWT is the content of some authentication result which can be used to be authorized against some resources. Since the JWT contains an access token, if you're using basic authorization, you'll add an Authorization header to your requests: Authorization: Bearer [your access token].
I am writing a ASP .NET WEB API Application which can be accessed by other devices and applications to interact with my Application hosted in IIS. How can I give OpenAuth Authentication for the WEB API Application. Am using MVC 4 in VS 2010 and hence my framework is 4.0. Please give me some suggestions.
You can authenticate a web API using Individual Accounts. Protected recource will contains the Www-Authenticate header with value "Bearer", indicating that the client must authenticate using a bearer token.
A bearer token is a particular type of access token. An access token is a credential string that authorizes a client to access a protected resource. (See RFC 6749.) A bearer token is an access token that can be used by any client. In other words, a client can use the token without proving that the token was issued to that particular client. (See RFC 6750.) For this reason, bearer tokens must be used with SSL. If you transmit a bearer token as plaintext, anyone can intercept it and get access to the protected resource.
All info about that can be found HERE