What I purposed to do is, I want to do is I want to create a Claim based Authentication.
But I use a public Auth provider such as LIVE connect API.
So it only return OAuth based data to me.
Considered I'm the server side, I just want to
1 get the data with OAuth.
2 convert it to claim.
3 set current principal to the claim I created.
Do I need to create a STS?
And can I use these this claim achieve SSO?
And have a look here where he actually implements it.
Or here which shows how to do it with Azure ACS.
You create Security Token Service (STS) when you want to decouple your authentication logic from your business logic in a way that it works as two separate services / applications, where one is issuing Security Tokens, and the other one (or more of them) are consuming them.
To me it seems that you should implement your own ClaimsAuthenticationManager that will convert all the data received by OAuth (which is doing authentication for you) to claims, generate ClaimsPrincipal with it and add your own business logic claims to it as well => set generated principal to be your current principal.
Depending on what libraries are you using for OAuth, some of them will create initial claims principal for you, which you can then take in ClaimsAuthenticationManager, and convert it to your own claims principal.
For more reference on it, check www.leastprivillege.com, Dominick has nice series of articles about OAuth and claims based authentication.
Related
OAuth 2.0 protocol provides permissions delegation of a user so that third-party apps can operate on its behalf. A typical way this is done on the OAuth flow is requesting a user consent to either approve or deny access for the app (Okta example). Here is an official spec describing how it works in general concepts.
I'm looking for the standardized approach to perform the same flow but for the user groups (e.g. organizations). GitHub does that in some way for organizations, so it looks like organizations represent just a group of user accounts. Are there any standardized approaches to this problem?
If not maybe there are any recommended ways how its typically done architecturally or can fit into OAuth 2.0/OpenID Connect protocols.
The OAuth 2.0/OpenID Connect protocols do not cover how access control is performed.
You can, within the OAuth 2.0/OpenID Connect protocols, pass OAuth Scopes or use the OIDC user info endpoint data to allow the resource server to make determination for Access Control.
Many of the commercial products within this area allow the use of LDAP as a back-end for authentication and will even convert LDAP Groups to Scopes.
I would assume, but I do not know, that GtHub stores data with a link (like a group) for the on Organization and/or the user. I know GitHub exposes this using OAuth Scopes.
Oh, and the OAuth Spec is at: https://oauth.net/2/
But if you require Authentication of users then you need to be using OpenID Connect which is built on-top of OAuth 2.0.
Remember that "OAuth 2.0 is NOT an Authentication protocol"
-jim
There are limits to what you can show on the consent screen and dynamically calculated data is not usually supported.
You ought to be able to express a high level scope that you can present to the user though.
In terms of authorizing based on a user's organisations the claims caching technique here can be useful:
https://authguidance.com/2017/10/03/api-tokens-claims/
That is:
* Use OAuth for user identification and high level checks
" Then do the real Authorization based on your back end data
I'm making some assumptions here, but I believe the issue arises from trying to authenticate two things at once.
If the organization is what you need, then go ahead and create a flow to authenticate the organization as the principal subject (via a user who has access to it), instead of actually authenticating the user itself.
Once the access token is generated, you do not necessarily need to know which user generated it anymore (or at least, the token itself does not need to know). If your user needs to be able to view and/or revoke access tokens, they should still be able to do that, since they have access to the organization in your app.
I have a DashboardApi and an EnterpriseApi on my system. May be one more later.
I am new at IdentityServer3 and I wonder solve my problem.
IdentityServer saves client applications that will use an api. So I have 2 or 3 api. Will I create IdentityServer for all api? Because DashboardApi will consume EnterpriseApi. EnterpriseApi will consume another api.
And users will login to Dashboard application. I could not imagine the organisation.
To answer the question: you may have one instance of IdentityServer being your identity provider/authority across different "resource" APIs as long as they all point back to that same authority when it comes to token validation.
Then an access token used for "DashboardApi" can be used by "EnterpriseApi". It is important to proxy the token properly and in my experience it would be advantageous to create different scopes for each API to have better access as to which calls may be used to proxy into the second API through the first (especially if user consent is a concern).
Inside my startup.auth.cs I do:
app.UseOAuthBearerAuthentication()
And I feed it an OAuthBearerAuthenticationOptions with a bunch of options tailored to using an Azure Active Directory B2C tenant. This by itself is functioning well. I am able to login with my MVC app, acquire a bearer token and make calls to this Web Api 2 project and I see a valid authenticated Identity. All is well.
However what I need to do is do a little more work in the validation process and add some custom claims to the identity. I am trying to figure out where the best place is to do that. For example, in my MVC app using OpenID, I can use the OnSecurityTokenValidated notification of the OpenIdConnectAuthenticationOptions to add claims. This new token/identity with my new claims seem to be cached somewhere throughout the mysterious vastness of OWIN such that the identity of subsequent calls have my extra added claims without having to go through OnSecurityTokenValidated every single time.
For the OAuthBearerAuthenticationOptions counterpart, I tried adding claims in ValidateIdentity() of a custom OAuthBearerAuthenticationProvider. This works, but I don't want to incur the performance hit every single time a call comes in because this callback is hit every single time, not just once during token validation.
So my question is if there is some place throughout all the Oauth Bearer token classes and OWIN middleware stuff where I can do this that is similar to ValidateToken() for the OpenID counterpart, or do I have to write my own caching mechanism?
Thanks.
I am developing a WebAPI over my already existant MVC application, using the OAuth2 authorization system.
This API will allow my clients to request my users information. Currently, my users are stored in the Identity tables (ASPNetUsers). In my application, they are registering, logging in, etc... with the help of the Identity classes and methods.
The problem is here : I want to manage my API clients accounts, in an "Identity way", so I can authenticate them when they ask for Access Tokens. But I can't use the current users tables, as there is no common points between my clients and my users.
The perfect solution would be to have two Identity tables : one for my users, and one for my clients, but after my long-time searches, I figured it was not possible, or it would be a mess, at best.
I would not use ASP.NET Identity as a way to manage OAuth2 registered client applications. Even though some client applications (confidential) are indeed issued client credentials that's probably the only thing they share with a username/password user identity. It's a completely different thing and as such it should be managed and stored independently.
If you're thinking that this sounds like a lot of work, you're absolutely right. It isn't trivial to implement a custom username/password authentication that proves secure and implementing an OAuth2 authorization server is many times as complex.
If you really want/need to go that route then some mandatory reading:
The OAuth 2.0 Authorization Framework
OAuth 2.0 Threat Model and Security Considerations
JSON Web Token (JWT) (assuming you choose JWT as token format)
If you're still evaluating all your options I would also consider the possibility of delegating all the authentication/authorization work onto a third-party, Auth0 comes to mind, but I'm biased because I work there.
Context:
We have a monster ASP.NET MVC 5/Framework 4.5 application that is planned to be divided in several others, so each new application will deal with a specific business domain instead of many. All those applications together will provide the same functionalities and services that are provided today by the existing single application.
We plan to use our own OAuth server to provide authentication and authorization for all the new smaller applications, so the very same users that use the current large application will have the same rights in the same functionality.
Currently we use Windows Authentication mixed with a secondary custom structure to establish what a certain user can do. We have our own role provider to generate the roles assigned to the users. When a certain controller action asks for the list of roles af a certain user, our role provider search in our custom structure and provide those roles, following specific business rules that make sense in our application.
We understand that the same rules that establish the set of the roles assigned to a certain user will be moved to our OAuth server.
We understand that the role-based security will be replaced by a claim-based security.
We understand that we will stop testing for roles and start testing for claims.
We understand that the first step of this refactoring should be add external authentication in our current large application and then start to break it into parts so we will have our new ecosystem.
Question:
How to change my current large application so it authenticate and authorize requests by using the new OAuth server instead by itself?
Note:
I´ve read a lot of blog posts but so far I couldn´t find a simple code sample that shows me what to do to instruct my application to go for an authentication/authorization token in my OAuth server and use it to grant or deny the access to a given controller action.