IdentityServer3: Can it be used "side by side" with existing users/authentication? - asp.net-mvc

I'm new to SSO, so hopefully what I'm asking makes sense. So my current setup is a .NET MVC website using OWIN/cookies (app.UseCookieAuthentication()) and a custom user table (not ASP.NET Identity users).
So I'm wondering if I could add IdentityServer3 only for external providers, but leave all my existing user/authentication stuff as is for "local users". So I see that you can implement a custom IUserService to lookup users against your local database, and I think I got that working, but I'd like to even avoid that. And I'd like to avoid themeing the IdentityServer login screen. So something like this:
User hits up page with [Authorize] attribute.
User is redirected to my existing login page (not IdentityServer stuff)
Then my login page would have the external provider button(s) to login with external providers.
Is that possible? Or do you have to run your local users through IdentityServer3 also? I noticed I get an error if you don't provide a IUserService and don't use UseInMemoryUsers() either.
So from following various guides, I have this in my Startup.cs: app.UseIdentityServer(), app.UseCookieAuthentication(), and app.UseOpenIdConnectAuthentication() with Authority set to my IdentityServer endpoint.
Hopefully that made sense, Thanks!

Gonna answer my own question if it helps anyone else. The important piece here is AuthenticationMode in OpenIdConnectAuthenticationOptions. AuthenticationMode.Active is what will redirect the user to your OIDC provider anytime they hit an action with [Authorize].AuthenticationMode.Passive will allow you to use your OIDC provider as an additional authentication method. You want to follow the examples with ExternalLogin() and ExternalLoginCallback() controller actions that issue challenges to the provider and then match the authenticate user with your local user.

Related

spring security role-based needed for full stack app?

I am implementing a basic login app. here are the features:
Upon successful login, there should be a welcome page that shows the name, username and role (manager/user).
If the user has a manager role, the welcome page will have a link to access a restricted webpage.
This restricted webpage can only be accessed by a manager role and not by other user roles.
implement logout functionality.
If the userid or password is not valid, I should remain at the login page with an error message "Invalid userid or password".
All data should be stored in a database.
The application should demonstrate MVC pattern...
my schema:
enter image description here
i am using react js for the front end. i build the backend using spring security with the role-based authorization where certain url can be accessed by certain role. i already do a testing on backend end using postman where i try to access /restricted and it responded with 401 if i use ROLE-USER instead of ROLE-MANAGER by using the mvcMatchers(). now the confusing part is the frontend
i noticed i can do all the necessary validation on the front end. i dont even need to do mvcMatcher() on the backend as i can just load the userdetails and roles and ask react to validate for me! hell, i dont even need to use role-based authorisation. i just need to add extra field in user table named "role" and use that to check for item 3 and display the role on item 1. i just need 1 table, not 3. i can even ask react to redirect to /login if user is trying to access /welcome without login, or disable /unauthorised if user role is USER.
but i dont feel right about this way. i'm confused.
a. whats the best approach?
b. is role-based only applicable to rest-api services, not full stack app? from what i see front end can do ALL validation
back end repo
front end repo
a. The Best approach is to have authorization at the back-end level because your React front-end is not the only way to access the back-end. If the back-end doesn't have authorization implemented, then even if you have validation on the front-end, a malicious user can use any other HTTP client to access the back-end without authorization.
b. Role-based authorization is applicable in all scenarios in which you want to allow access to resources based on user roles, no matter which stack is used.

How to manually set the current user in the OAuthAuthorizationServerProvider' GrantResourceOwnerCredentials method?

I have an asp.net mvc webapi 2 project and I'm using the new asp.net identity infrastructure with owin and oauth and all its great features...
I'm using for authorization the token based system: app.UseOAuthBearerTokens(OAuthOptions);
Everything works great, the only issue that I have is the following - in my own OAuthAuthorizationServerProvider implementation, in the method GrantResourceOwnerCredentials (the one that gets called once an user wants to authenticate by visiting the /token url), after checking the user validity and other things, I need to call other methods (recalculate shopping cart, etc) but those methods (don't ask why) looks into the current context User to get the username and role of the user, but during the running of the GrantResourceOwnerCredentials method, the current context User is null (is somehow normal - I'm not asking why).
My question is: in order to not break any guidelines of using the oAuth bearer tokens authorization is it OK to manually set the user in this method like this?
context.Request.User = new ClaimsPrincipal(oAuthIdentity);
Thank you for your feedback.
in owin startup orders of bearer and authorization must be like this
app.UseOAuthBearerAuthentication(new OAuthBearerAuthenticationOptions());
app.UseOAuthAuthorizationServer(new OAuthAuthorizationServerOptions());
Check out this answer

How to authenticate from a token in a URL?

I need to create a website with non standard authorizaion logic (or rather not exactly the site. It should be separate Area in existing ASP.NET MVC3 application). Access to most of the pages sould be available only to authorized users. Authorization is carried out on the token passed in the link. After the user arrived to this area, the token should be checked and if it’s valid site will create a session key for 30 minutes (we already have our own mechanisms of session managment and it should be used).
Workflow example :
Third-party website generates a link for user, e.g. https://example.com/securedPage/?accountId=123456&token=XXXXX
Our site check this token (it depends on the page from URL, in this case https://example.com/securedPage/)
If the token is valid, example.com obtains a session key for the user and stores it in cookies.
Then user continues browsing whole website and only session is checked.
I’m new to MVC framework, so I’d like to ask several questions about architecture.
What is an apropriate place for this logic? ActionInvoker, Global.asax etc.?
Currently I'm trying to create my own ActionInvoker and keep this logic there, but I'm afraid that it could be a wrong way.
If I understand correctly you want yo extend the Action of the controller to inject/check your token.
I think the global action filters should help you.

Is this really all I need to log a user in?

I was looking over some ASP.NET MVC 1 code (C#) in search of the mechanisms that the site was using to log in a user. This is what I found...
FormsAuthentication.SetAuthCookie(authenticatedUser.UserName, false);
followed by a redirect. Is it REALLY that simple?
I couldn't find any other code after the redirect that would be responsible for this.
FormsAuthentication.SetAuthCookie creates an authentication ticket for the supplied user name and adds it to the cookies collection of the response, or to the URL if you are using cookieless authentication.
This will "log in a user" but you need to actually make sure the user exists somehow. You can use the built in membership providers which will by default target a SQL Express database in your App_Data folder called ASPNETDB.mdf.
If the default membership provider does not work for you then you can create a custom membership provider by inheriting from the base MembershipProvider class. If you don't want to do this then you can roll your own solution and still issue an authentication ticket, but at the very least you need to do something to actually make sure a user is who he says he is.

Setting up a private beta for a website

I'm trying to setup a "private beta" for a site that I'm working on. The site uses open id. I don't want anyone to even browse the pages if they aren't part of the beta. What's the best way to implement this? Any suggestions?
For example:
When the site goes live, users will go to http://www.mydomain.com which will not require them to log in.
For the beta I want to restrict access. Users that go to http://www.mydomain.com will be redirected to a login page. Anyone attempting to access ANY PART OF THE SITE who is not authenticated will be redirected back to the login page.
I could stick [Authorize] attributes all over my controller actions, but that seems stupid.
If you're using ASP.NET MVC, it comes with authentication/authorization out of the box. You should be able to use that to setup authentication on your site.
Alternatively you could setup app server settings - IIS lets you setup username/password on a specific site it's serving, regardless of what the actual application may do. If you have access to the app server this might be the best solution.
If you're using IIS6, you can setup authorization easily. Right-click on your site > Properties > Directory Security Tab > Authentication and Access Control > Edit, and enter a username/pwd of your choice. Done.
The real question is how are they being invited to the private beta?
You could setup a password which drops a cookie much like serverfault.com does.
OR
If you know who you are inviting: you could add them to the system before hand using the email/login information that you already know about them (assuming you are inviting them via email)
I have implemented a function in a web application a while ago where we go the possibility to block access to the full website unless the user was an administrator (which in our case meant that the user account was a member of a specific group in Active Directory).
It was based on two things. First, all pages in the web application inherited not directly from the Page class, but from a custom page class in our web application. Second, we had a value like this in the appSettings section of web.config file:
<add key="adminaccessonly" value="0" />
The custom page class would check that value when loading. If it was not 0 it would redirect to a page (that did not inherit the same custom page class, though) informing the user that "the site is not available right now". If the value was 0 the page would load as usual.
In that application we used this to be able to take the site "offline" when we deployed a new version, giving us some time to verify that all was good before we let in the users again.
Best way are invitation system (based on invitation code) or manually confirmation access after create profile in your system. imho
Or you could host the site on a private server, and set up a VPN to use it. Depending on your resources and needs this may be the easiest and most secure way to do what you want without modifying your codebase.
OR alternatively you could use Apache or IIS to force authentication on access to the website directory. Keeping the authentication info in .htaccess for a while.
Even though you use open id authentication, you may still need some form of authorization mechanism. The simplest form would be a user-roles system in your database that assigns different roles to users
In your case, just assign the private_beta role to your private beta invitees and ensure you your authorization mechanism that all users have private_beta privilege before they may continue.
If you don't want to provide authorization for the public site (where everyone can do everything, once authenticated), then, you may only need to do a quick-and-dirty post-processing (for private beta only) on your open_id authenticated users to check them off a short list (which you can store on a text file.

Resources