I am writing an internal app where all the users are part of AD. I have the following steps to implement this. Is this correct?
Create Action filter to get all HTTP request to website and check in they are in the specific AD role needed (var isUserInRole = User.IsInRole("M2-ITU-PWApplicationDevelopers"))
If user is not in any of the application roles send user to error page
If user is in application role then Add users to SQL DB and link to Role table in DB so now I have the user/role data ready to use in DB along with other data
When user revisits check the database first before LDAP?
How do I set a cookie or something so that every request does not need through process once authenticated ?
Trying to understand the basics.. Maybe I am going about this all wrong ?
Use Windows Authentication. Your application need to be behind IIS to do it in ASP.NET Core 2.2 and lower, but starting ASP.NET Core 3.0 you can do it with Kestrel alone.
If you do that, you can skip steps 3 and 4. When a person is authenticated via Windows Authentication, the application gets a login token that contains all the security groups that the account is a member of. So User.IsInRole is pretty quick. There is no need to store that information in your own database.
You also don't need to worry about cookies.
The added benefit of Windows Authentication is that it can support seamless login: if your site is in the Trusted Sites in Internet Options, then IE and Chrome will automatically send the credentials of the user currently logged into Windows. The user doesn't have to type in their credentials.
Firefox uses its own network.negotiate-auth.delegation-uris setting for the same purpose.
Related
Hi I am working on Angular SPA and web API core. I am trying to implement authentication and authorization. I have done as below for now.
Registered one application for my front end application and added required redirect uri and modified manifest file to enable implicit flow. Also assigned some of the roles to it.
Registered one more application for my back end. I added scope in the form api/clientid. Then added client application id which is created in step 1.
User is successfully able to login to application.
Now my JWT token has roles in claim. In my API I have added [Authorize(Roles = "Engineers,Admins")]
So If user has any role Engineers or Admins in the JWT token as claims then they are allowed to access my API's
So far my authorization works fine. But coming to authentication part, currently all users of my azure AD tenant able to do login(User can hit my front end url and add user name and password then It will ask MFA and they will be landed in application home page).
If user is part of any of the roles above then only they can see data in home page because in home page I am calling some of the API's and I have added [Authorize(Roles = "Engineers,Admins")].
If suppose user is not part of above role they are still able to login (login means they are able to add user name and password and MFA) they will be landed in home page but they cannot see any data because api will be accessed only if they are part of Engineers,Admins roles.
My question is If user is not part of Engineers,Admins roles why they are able to login and come to home page. They should be restricted in Login step itself.
I am not really sure I am asking right thing here or I only confused my self between authentication vs authorization.
Currently I am doing authorization based on roles. Same thing I can accomplish using Groups also. In claims I can return groups and create policies and do the authorization. If user is part of the group then I can authorize. I am trying to understand what advantage I will get using roles over the groups.
Currently I have dev, prod and non prod environments. But Azure AD is universal and for there is no environment for azure AD. So Is it a good idea to have separate application registered in azure ad between the environments or can I use same app registered in azure AD between the environments. If I create separate application for each environments what advantage I will get?
I am really trying to understand above concepts and can someone give me some insights on the above things? It will be really helpful to me If someone help me to understand this concepts. Any help would be greatly appreciated. Thank you
Background:
I have a basic user database with username(email) and password. The users are able to sign in to a website of mine with these credentials. From the website they get a link to different services they have access to, but with different username/passwords. So they click the link "Open My Service X" and they have to login with their service unique login credentials. I do have the users service login-username. So I can map local-user <=> service-user.
I want SSO between service X which has support for SAML and my website.
Question/Problem:
I want the users to login with their user/password in my database, then single sign on towards service X where service X has support for SAML. I don't want a user to be able to sign up for a new user account to my website using the SAML support in service X. The user must already have an account in my database.
So my question might be rather vague, but I'm having a hard time to grasp how this can be achieved?
I was thinking of letting my webapp become a SAML identity provider, so that the SSO request are transferred back to my webapp and verified for their service-user. Would that be correct approach?
You're on the right track with your SAML IdP. There are basically three parts involved. Your email database (the identities), your existing application front end and the remote services which support SAML. Usually it's SAML2 these days.
To get single sign-on (SSO) across your portfolio of apps (your own app and the remote services) you could install an IdP like the Shibboleth IdP and convert your app to use it instead of using email/password to login. That would take a fair amount of work as you'd have to convert your app into a SAML SP, just like the remote services.
An easier way might be to only use the IdP for SAML to the remote services and get the IdP to recognise that your users are already logged in with their email/password. Cookie? So the IdP should never display a login page as it would recognise your app's cookie and match that with a user in the database. It then releases SAML attributes to the remote service based on that user's information. That also covers your use case of not allowing account creation via SAML from a remote service.
That would mean you might end up with the following URLs:
https://yourapp.com/
https://yourapp.com/idp/
Your users login with the first URL as normal and the remote services use the second URL. That way your app cookie will be visible to the /idp endpoint but you'd need to write code to match that with a user in the database.
I have a solution with 3 projects in ASP.NET Core:
MVC --- no DB (calls the API)
Web API --- MySQL 5.7 own DB
IdentityServer4 + ASP.NET Identity --- MySQL 5.7 own DB
I've managed to get authorization and authentication working between all three apps using in memory clients, users, resources following the great documentation found on https://identityserver4.readthedocs.io/.
Currently I'm using the HybridAndClientCredentials flow which works well with existing users as well as registered users. Newly registered users are saved in IdentityServer DB, using ASP.NET Identity tables.
The problems:
One of my client requirements states that the user should have a profile page inside the MVC app to which the user should be redirected after he is authorized & authenticated successfully.
What I'm doing right now is calling the API in the MVC app, OnTickedReceived event, with the initial claims to create the user in the API DB, but I have doubts that this is the correct implementation.
Since the registration is done and persisted at IdentityServer level and some data about the user is stored there, should I make the profile page there too or should I make a call to the API somewhere in the registration flow to create the user in the API DB too, then redirect the user to the MVC app to input the rest of the details required for a complete profile?
Another requirement states that a user should be able to grant read/write access to another user's details (as in linked accounts or something).
Unfortunately, "it depends".
Let's start by asking "what is the profile page?". What information is on the profile page and is that information specific to your application (MVC/WebApi) or the identity management system.
IdentityServer supports the OIDC UserInfo Endpoint and Profile scope with ASP.NET Identity so that could work well. (http://openid.net/specs/openid-connect-core-1_0.html#UserInfo). You can insert IdentityClaims into the AspNetUserClaims table and get those back when you call the UserInfo endpoint.
But maybe this profile page mentioned in the requirements is information belonging to just the application's domain and therefore has no business being in the identity management system. Then, your current approach is ok- though maybe you could use a Filter Attribute instead of an authentication event (that's just a thought, might not be better).
To me, the decision is about who owns this so-called "profile" information. Is it the identity management system or your business application.
If the profile information can be shared across any client of the identity management system, then put it in the identity management system.
I'm developing an Enterprise/Internet Application with WebAPI 2 RESTful server and SPA web client (Angular2) —So I have two separated projects created using ASP.NET 4.6 Empty template and both use OWIN and are IIS hosted.
The requirement for Authentication is:
Active Directory user which is logged in to the workstation will authenticated automatically once she opens any page from app in the browser if user id/name found in the database, with no need to enter her user/pass. Let name this as auto-login. Else if it's not found in the DB it will redirected to the login page.
Also there should be a logout option which redirects user to the login page after logging she out.
In the login page any AD user can enter her/his AD user&pass and after successful check against database (existed) and AD (valid credential) she/he will logged in to the system (Obviously it may be different than user currently is logged in to the workstation)
In addition to the web client it will have other clients such mobile apps which will connect and be served by the WebAPI back-end. Users will login there using their AD user & pass too. Let name it manual-login.
According to the REST architecture and having both AD enterprise and internet/mobile users together, the authentication should be token based —this is what I found till now but I'm not sure.
I read about OWIN Authentication architecture and Windows Authentication and I checked MixedAuth, Now I think it is the nearest solution for this requirement as it lets app-defined users to authenticate side by side of windows/AD users. But even after dig into it and its SPA sample I didn't found my way yet and confused.
Anyone can help?
What should I actually do on the WebApi server and SPA Client to accomplish those authentication requirements?
Which middlewares should I add and how should config/manipulate them?
UseCookieAuthentication ?
UseExternalSignInCookie ?
UseOAuthBearerTokens ?
Can I rely just on Bearer tokens (using OAuthBearerTokens MW) and get same token for authenticated windows users to unify authentication model based on bearer tokens? If so, how?
How and where should I put my code for checking that AD user exists in the DB and if not so reject the authentication?
Thanks a lot.
I am working on a prototype for a site re-architecture using ASP.NET 5 and I am debating using IdentityServer4 for my Authentication and Authorization. I have reviewed a lot of samples and articles about setting up IdentityServer3 and 4 and I am trying to wrap my head around if it can handle my client’s requirements in a proper way. Here are my requirements.
I have 3 sites that need authorization. Site 1 (abc.com) will require windows authentication and will be a combination of mvc and webapi calls using roles (or roles converted to claims) for authorization. Site 2 (def.com) is a trusted site that wants a login widget with a username/password/rememberme text box on their site that when submitted will authenticate the user and redirect them to site 3 (xyz.com). Site 3 will also have its own login page and will be a combination of mvc and webapi calls using claims. Site 2 and 3 will not be using windows authentication and the client does not want them redirecting to the identity server login screen, but rather having their own login screen and calling the identity server from code with the credentials to login.
Here are my questions regarding this scenario and IdentityServer4.
Can Idsvr4 handle one client using windows authentication and
another using username/password authentication?
If so, is there a
reason to have windows auth in idsvr4 or should it just use standard
windows auth within the webapp?
Can idsvr4 be setup to have the client collect the username/password/rememberme values and pass them through code to
get the proper jwt tokens for both mvc and webapi?
If so, can it
log them into both the mvc and webapi applications on another site?
If so, is this circumventing the real purpose of identityserver4
and therefor is a bad idea?
If it can handle this scenario and is a good idea, how would I setup the client, scopes and code to handle the login through code and redirect?
Examples are great and very welcome, but I am not even sure what verbiage to use to search for this scenario so even pointing me in the right direction would be of great help.
Not sure if this question is still active. But yes, i believe you can do all that.
1) You can setup which ldp is available for each client by setting IdentityProviderRestrictions on the client (docs)
1.1) - Not sure what you mean, i believe one of the points of having idsrv is to sentralize you authentication, and it makes it easier for future websites to integrate with the same service.
2) When logging in using a client (application), you also specify which apiResource the client has access to - and the application needs to add this to the requested scopes when signing in. So if your client is the mvc application, you just add the ApiResource in the AllowedScopes - and set the request_type to id_token code - this would then give the user a access_token that is passed with each request to the backend api. (docs)
2.1) - This would basically log the user in on both sites - using an access token that says that the user is authorized to use the backend api.
2.2) - In my opinion this flow is one of the things that makes idsrv great - and they even mention this as a great feature of idsrv themself. You just need 1 trip to the authserver to gain access to all systems.
as for pt. 3 - Take an extra look at the docs, try to setup a blank project following the quickstarts.
For logging in from your own login page, you need to use the grant type Resource Owner password - Altough they dont recommend doing this for security issues (transmitting passwords over the wire) - it is supported.