I have an duende identityserver that has multiple BFFs as a client.
One of these BFFs is for my admins.
My identityserver has multiple sign in schemes (Think facebook, google etc) however i want to force my Administrator bff to use the (Azure AD (for my organization only) login.
I was thinking maybe setting clientproperties in the database and having the identityserver respond to that. But i was wondering if there is a more standard way of doing it that I haven't thought about.
Some authorization servers have allowed authenticator settings, though others do not. I could not see a built in option in the client model.
Another option is for the client application (your BFF) to send the acr_values OpenID Connect request parameter to force that app to bypass authentication selection screens.
This feels like the preferred option in your case. After login your BFF could even validate the acr claim to check that the expected authentication method(s) was used.
Fun fact:
Duende identityserver has Client.IdentityProviderRestrictions
this is excactly what i needed for my goal
Related
I Will try to describe this as detailed as possible.
For using the SPA, you need to be logged-in, every request is authenticated by JWT. Login is a simple form with Username and Password fields, which are sent to the server. On the server, there are two types of login (kinda) - AD and Password (determinated by the user type):
API check if username exists and determine its Type
a) if type is Password: Check if password matches the data in Database
b) if type is AD: verify password on the LDAP server
successful login returns generated JWT, which is used for all further requests.
This App is available all over the internet, not just inside the same network as the server.
I would like to have some kind of "automatic login" with Windows account (so you dont need to manually type the username/pass, but the SPA tries to login automatically when u open the Login page).
I tried many guides for something like this, but nothing seems to work properly.
I heard that Kerberos/Auth0 should do the work, but I dont know how to implement it. Also I would still need to get that JWT for further requests. Do I need some kind of Microsoft request? Azure? Anything else? (If is needed, I can create another IIS application just with Login controller).
I hope you understand what I mean, and will be able to help!
Most Modern Browsers speak SPNEGO
Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO), often pronounced "spenay-go", is a GSSAPI "pseudo mechanism" used by client-server software to negotiate the choice of security technology.
It just so happens that one of those client-server security technologies it can speak is Kerberos. (Windows machines generally have kerberos availble by default.).
So to actually get .NET to use kerberos authentication you really need to enable delegation for IIS as that's what speaks to the browser.
we are using identity server to grant access to apis. All what we used (or needed) so far was ClientCredentials (machine to machine) where the user is not involved.
Now we got the requirement that users should be involved and we must deliver user permissions.
I have read a lot about Granttypes: Implicit, Authorization code, Hybrid etc... but still didn't find a clear answer about the best practises.
Is there any way to integrate user permissions in access_token (is this also a good idea?). The AspNetIdentity is already integrated and the tables are existing in identityserver database.
services.AddIdentity<User, IdentityRole>()
.AddEntityFrameworkStores<IdentityContext>()
.AddDefaultTokenProviders();
How to send client credentials and user credentials so our identity server can also collect user information (permission, claims, role, etc...)?
Any help is highly appreciated.
Thanks
You're confusing concepts here. Identity Server deals only in user principals (basically just a set of claims belonging to a "user"). The actual user management is out-sourced, most normally to Identity. Identity itself is claims-based, as well, with roles actually just being a type of claim.
Authorization is a whole other beast and doesn't technically explicitly involve either Identity or Identity Server, although they often act as the gateway to said authorization. Authorization can be role-based, claim-based, or policy-based in ASP.NET Core, and then there's the technically framework-agnostic resource-level authorization option. However, that's still going to ultimately rely on one of the big three: roles, claims, or policies. It will simply have an added component of being specific to a particular resource. Which way you want to authorize is entirely up to you and of course you can mix and match as well.
Ultimately, you're just going to set roles and/or claims on your user via the tools Identity provides, which of course, will be persisted to you user/role store. Then, when authentication occurs via Identity Server or directly, a ClaimsPrincipal will be created and added to HttpContext. When authorization is required, the claims on this principal will be utilized in some way to determine whether access should be allowed or not. Simple as that.
Identity Server simply acts as a centralized authentication provider. Since communication is happening over HTTP, it's actually going to be returning JSON, specifically a JWT. Then, ASP.NET Core's authentication middleware, which would have been set up to use Identity Server as its provider, would simply decipher the JWT and create the actual ClaimsPrincipal instance from that. You don't need to worry about any of that, though, past the initial implementation. Once everything is integrated, the fact that Identity Server was used is virtually inconsequential.
I currently have a .net core application that uses Identity Server 4 to authenticate users. We have two different applications; an MVC portion of our site that users can login to, and a SPA that users have to login to as well. Is it possible to make it so that anytime the user logs out of one of those areas, that it logs out of both?
This is the main idea of Single Sign-On. Not only single login, but also single logout. Identity Server 4 fully support this, but you just need to configure both your clients (the MVC app and SPA) with their proper configurations. This is the official documentation about signing out. It works.
EDIT
PS: Have in mind that Identity Server does not invalidate the access token, once you are logged out. In other words - if you, by any chance, still have the access token, you will be able to use it, as long as it is valid (its validity period has not expired). This is why usually the access token is set to have a shorter lifetime.
There are 2 front channel ways to acheive this and I'd recommend using both.
1) Front channel log out which uses an endpoint registered against each client. When you sign out of IDS4 (assuming it's implemented properly) it will make a request to the registered endpoint for each app that was signed into during the current session. http://openid.net/specs/openid-connect-frontchannel-1_0.html
2) The session monitoring spec which uses a bit of javascript and cross-domain iframe magic to notify the client app when the user's session changes on the IDP. Using this you can immediately respond to changes and do any cleanup you need to. http://openid.net/specs/openid-connect-session-1_0.html
As mentioned in m3n7alsnak3's answer this will not invalidate any JWT access tokens (you can use the revocation endpoint to revoke refresh or reference tokens however). Therefore I'd recommend having the client applications to the best job they can of clearing up any state they can, i.e. clearing all cookies, session/local storage etc.
I am looking for single sign on for my application which is built on javascript (no server side language).
Requirement:
Agent log in to Windows (user integrated to Active directory)
Open my web page
Based on who logged in to windows, my application goes to AD and pull some user
specify data (eg email, phone)
How shall I go about it?
As per my understanding I will require ADFS for this.
So:
User goes to my web page
My web page calls some Web services or web application (which is build on c#)
That will authenticate against AD FS and get claim
Either get phone number and email in claim or get username and query AD for phone and email
Return the data to my web page (build on javascript)
It seems there something wrong in my understanding!!
Please suggest more appropriate solution based on my requirement
Frankly, I can't think of a way to make it work without a server side processing. This is because the ws-federation protocol ADFS uses is not just about returning claims.
It is about returing a SAML token. The token contains claims but what is most important about it is that it is signed using the XMLDsig. How are you going to validate the token is a first big question. But there are surely external libraries that allow that.
But then, such authentication can easily be bypassed by modifying scripts in the browser. This is because the ws-federation stops where you get the token and then it is up to you to exchange the token for the actual identity. And this won't work when processed only at the client side.
ADFS 3 does not support the OAuth2 implicit profile, which would be an option, but still you would need to verify the token on the server to avoid session fixation.
You can setup something like AuthorizationServer that supports Oauth2/OpenID Connect implicit profile
http://leastprivilege.com/2013/09/19/adding-oauth2-to-adfs-and-thus-bridging-the-gap-between-modern-applications-and-enterprise-back-ends/
Another option is to use something like Auth0 (Disclaimer: I work for Auth0) which also supports OAuth2/OpenID Connect implciit profile. In that case you wouldn't need ADFS, there is a connector/agent that you install on your network that does not require opening firewalls or anything and it supports implicit profile that is suited to JavaScript apps. This is an example of a single page app tutorial (if you create an account it will tailor the doc with your credentials):
https://docs.auth0.com/singlepageapp-tutorial
I'm developing a WCF service that will host business logic of the application. The application is mostly for intranet, but can be accessed from internet. We have an active directory domain up and running, so I plan to authenticate and authorize users according to their username and groups they are in. This service will be used mostly be an ASP.NET MVC site
So, first question is how to authenticate and authorize users based on their AD profile?
Secondly, I need to store additional info about each user. The problem is that I can't modify AD scheme. The number of added fields is about 10 or so.
Can I somehow use SQL server for profile storage? Of course I can, but how to tie this with AD auth?
You can use WIF for this.
You would configure your WCF service for WIF in the normal way and then use a custom ClaimsAuthenticationManager class deriving from the base ClaimsAuthenticationManager and overriding its Authenticate method. This is a normal extensibility point of WIF. WIF will
get hold of the security token from the incoming request and add claims for each of the relevant AD properties. In your override of the Authenticate method, you will add new claims to represent your extra properties.
The basic use of WIF for WCF services is described here:
http://msdn.microsoft.com/en-us/library/ee748476.aspx
To see how to use ClaimsAuthenticationManager, start here:
http://msdn.microsoft.com/en-us/library/ee748211.aspx
Well, I think you have a couple of choices here, but you will have to carefully consider the implementation.
The primary issue with using active directory authentication is that by default a user's credentials can only be passed successfully between two machines. In the case of a web application, this means that the user's credentials can travel between the end user's machine and the web server, but no further.
However, this behavior can be changed through the use of Kerberos authentication, which essentially allows an authentication ticket to be passed among all of the trusted machines in the chain (i.e. from the web server to the application server to the database, for example). Successfully configuring Kerberos can be extremely challenging, especially if you have had no prior experience with it.
I think your best bet is to configure your web site to accept only Windows Authentication. This means that IIS will perform the validation of the user against active directory. In your ASP.Net application you can pickup the domain name of the authorized user from Request.ServerVariables("logon_user").
At this point, you can log the user on with FormsAuthentication, for example, without requiring them to login again.
You could then either implement the SQL Server Membership Provider or create your own interface to your database for further user validation and extra information storage. We have used both mechanisms, but I prefer the self-built one due to the additional control it provides and, in this case, you won't need a lot of the functionality (password reset, recovery, etc) that the membership provider offers.