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.
Related
I have a SaaS application using Vue.JS as frontend and Django Rest Framework as backend. I use JWT tokens for authorizing between frontend and backend.
Now I want to add support for our customers to be able to sign in with their Microsoft accounts. So if the signed in user matches a user in our database, it is logged in to our application.
I've set up Azure B2C and can successfully log in and acquire a token in the Vue.JS application using msal library.
Then I send the token to backend server for verification. I use azure_ad_verify_token to verify the token, but I get an InvalidAuthorizationToken exception.
It seems to be working when the user is added to my organization's AD directory. But I would like to verify the token for any Microsoft user, then match it to users in our database. It would be too much work to manually add our customer's users to our AD directory. If it would be possible to add another organization/domain I guess that would be ok.
There's a lot of documentation regarding this but I always end up in examples for separate applications. Just to clearify flow I try to achieve.
The user clicks on login with microsoft
The user is redirected to Microsofts login page, approves my application for their organization
On requests sent to our backend, the token should be verified against Azure Active Directory using authorization class.
If the user's email exists in our database, the request is successful
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.
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 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.
Basically I just want to know how does StackExchange's single signon system work?
In the SE network you need to login only once in one of the websites to be automatically logged in to the other sites upon visiting.
How should I implement such a feature in my own network of sites?
I assume it uses the cookie which resides on the user's browser and then authenticates it with the originating site. If it is legit then it logs the user in automatically.
You have to implement SAML or oauth2 to allow sso on your network.
In case of SAML your child websites will be service providers or resource servers.
While you need to setup and identity provider.
The sequence of events will be like this.
1. User hits a url of songs website, this site is resource server and does not handle authentication.
2.To authenticate resource server will construct a SAML authrequest and redirects to identity provider after signing it.
Idp verifies the signature after receiving authrequest.
3. User will be presented with a login form, user has to end login credentials.
4. After user authentication idp will generate a SAMl token and redirect back to resource server.
5. Resource server will extract identity information from SAML token, resource server will login the user with session or cookie.
Depends upon which technology you are working in i have implemented it in php using simplesamlphp.