I would like to know if it is possible to implement impersonation in IdentityServer 4, and how to do it.
Did not find anything useful in my researches, and it seems, by reading IdentityServer4 pulls on github that it is not doable at the moment. Even searched for "impersonation" for OpenID Connect and Oauth2, but nothing...
Anyway does anyone knows how to do it?
Thanks in advance
Nothing stopping you from implementing it yourself but I think anything beyond representing an impersonated session via claims is outside the scope of the protocol.
OIDC itself does not offer any guidance in this area but this draft spec does:
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-exchange-14#section-4.1
In our case we loosely followed this and used the act claim to store claims relating to the impersonator and used the amr claim to indicate if impersonation was used by using the value imp.
The rules and flow around who can impersonate who and when is entirely up to you. In our solution end users are able to grant impersonation permissions to specific users but this facility can be locked down via customer-controlled policies too. Users with valid impersonation grants get an extra step in the sign in flow that allows them to choose which user to impersonate.
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'm implementing my own OpenID Connect provider using Identity Server 4.
I understand, that once issued an access token, clients can use it to obtain claims about the end-user from the userinfo endpoint. Which works great, by the way.
However there are certain use cases where it might be necessary to obtain claims about other users in the system. Think about a user who is head of a department. Clients might want to get email addresses of other users in this department on behalf of this user to notify them about something.
My question is: Is such functionality covered by OpenID Connect or is there a feature in Identity Server 4 to help with this?
I see that I could implement this myself by exposing part of my identity service as just another api protected by the identity server itself. For my use case it would probably be enough to flag certain claims as public for other users, so they can be accessed like any other resource. However there might be some security issues I might be overlooking. Also I would be interested if there was a non-proprietary way to do it, so it could be used by arbitrary clients, and show up in the discovery document.
Any input on this topic would be highly appreciated!
We are trying to split apart Authorization and Authentication into two separate services. Both will use Identity Server 4. We may someday add in additional external Authentication providers. I believe Federated Gateway is the term (http://docs.identityserver.io/en/release/topics/federation_gateway.html?highlight=Federation)
My research so far indicates we are able to setup Authorization as External Providers and set [LocalLoginEnabled] to false. This works fine for web apps, since it redirects along the traditional flows. Our requirement is to have both Web-based and client-apps (Windows and Mobile) calling our solution. This would need Implicit or Resource Owner (password) flows.
Looking for guidance on the best way to set this up. I'm tempted to write a custom endpoint API to relay the authentication to authentication instance.
QUESTION:
How can I achieve "password flow" between two ID4 instances (Authorization + Authentication)?
Thanks in advance!
After much research and little guidance, I decided to take a leap and just created a new API Endpoint used only for Resource Owner / Password Grant Types. This API simply validates the necessary information was present grant-type, secret, user/pwd etc... and then relays it to the Authentication instance. There may be more "elegant" ways of doing this, but this one seems to be working.
Hope this might help someone.
Although my original answer worked, it was not the best way to accomplish my end result. Instead of creating a new endpoint, I am able to inject my own handling of password grants by extending the IResourceOwnerPasswordValidator. I can then have a single endpoint for all authorization. This solution is more "natural" and falls inline with the intended architecture.
The IResourceOwnerValidator interface just implements one function...
public Task ValidateAsync(ResourceOwnerPasswordValidationContext context)
A much more elegant solution.
Does OpenId support a two way exchange of tokens at any place in the spec? Specifically allowing both parties to share tokens with each other in some way so they can share services with each other?
I've looked through the spec, but can't see anything detailing any scenarios like this.
An app I'm working on has integrated itself with a trusted OpenId provider, we'll call Acme.
We'd also like to provide access tokens and refresh tokens to Acme, as they'd like to access features of our service as well.
It seems natural that during our interactions to get tokens from Acme, that we'd like to expose tokens to them.
Is this part of the spec in any way? Or is the only way to do this is to become a full identity provider ourselves?
You could include the tokens as part of a request object, see: http://openid.net/specs/openid-connect-core-1_0.html#RequestObject but that would depend on a pair-wise agreement with Acme since they'd need to handle the non-standaridzed request object contents.
The best way forward is to become a provider yourself so you can leverage all the features of the various flows without being dependent on a pair-wise agreement and accompanying implementation.
It sounds like you're confusing OpenID Connect and plain OAuth2 to some extent.
OpenID Connect is a specification for identifying end users to a client application, based on their authentication at the OpenID Provider. It's not clear from your question whether end users are even part of the picture, so even plain OAuth2 may not be relevant (unless you are just using the "client credentials" grant).
Neither spec says anything about mutual exchange of tokens. It would probably help if you describe the interactions you anticipate in more detail and which grants you expect to use. Who will authenticate to your identity provider and what would be a typical client application?
Can you use oAuth to only authenticate like you can with Twitter?
If you check Google's docs at http://code.google.com/apis/accounts/docs/OAuth2.html you'll find that the scope (meaning, the service you're supposed to ask permission to) is a required field.
It may be a turn off for many users if you ask them to access their contact list when the most you really do is authenticate, so I rather stick with OpenID which is designed just to retrieve the UID.
So, the answer is really NO, unless you're planning on using an additional API with Google.
OAuth is an authorization protocol and can't be used for authentication only unless the provider defines a dummy scope which, in effect, authorizes you to access "nothing", or "basic user info" (name, e-mail, etc.).
AFAIK, Google provides no such "dummy" scope. However, they do implement OpenID for such authentication purposes, as the protocol is better suited for that task, anyways.
Yes you can there are many options it depens on your platform advice you to check
oauth.net
You can find there options for Java, .NET, Cold Fusion,PHP,etc.
There are many Frameworks that have OAuth capabilities, on Spring you can use this
Sounds like there is some plans afoot on this...
http://googlecode.blogspot.com/2011/03/making-auth-easier-oauth-20-for-google.html?showComment=1300267218233#c6336940633709651714
some chap:
"Can someone help by pointing to the documentation for the API of "just get basic information for a user"
other chap:
"The problem is, that you get a lot of different login mechanisms because Twitter is using OAuth 1.0 (Or am I wrong?), Facebook is using OAuth 2.0 and Google is using OpenID for login. Please correct me if I´m wrong. So basically I have the same question.
Will Google support login for basic user informations with OAuth 2.0 for Google APIs?"
google dude:
"Today we're supporting OpenID for login, but we've heard your pain about mess of different identity protocols on the web. Stay tuned :)"
Seems to me, as OAuth2 covers authentication and authorization, it would make sense to allow basic info and make it easy on the integrator using one method for all
I'm plumping for this possibility anyway, hopefully by the time I'm ready to put my app live it will be available from Google - Facebook has this anyway and in my case that's a big enough draw