Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Scenario:
IIS ARR front-end is distributing load to n. IIS app servers running MVC 6.
Multiple domains point to the ARR
Using MS Identity authentication
All Appservers serve the same application with slight branding/content changes depending on which domain was used to access the site. We'll call each variation a "portal".
Can you verify the following assumption?
Identity auth tickets appear to work out of the box for this scenario.
Specifically, If a user logs into the site under "www.foo.com" and then hits the same site using "www.bar.com" that they will not appear to be authenticated at bar.com (even though they are technically hitting the same application, on the same or different App server).
Are there any gotchas with this?
Can you check this architectural decision?
We've linked in a MVC 6 middleware component to inspect the domain of each request to set a "portalID" variable in the HTTP context's Request object. The component just checks the domain name against a Hashtable and sets the appropriate portal ID for the request.
Variable content is rendered using partial views and the new view components. All variable content (like header image references, text, etc) is stored in a database and IMemoryCached cached and varied by portalID
When a user registers, the registration method tags the user with their PortalID (we only have one user DB for all "portals", but want to keep the users segmented).
Is this a reasonable way to implement this scenario, given the new MVC 6 framework?
Can you think of any gotchas with this implementation?
In regards to authentication, auth tickets (cookie-based authentication) are per domain so you'll have no problems with a user accessing Portal A when only logged into Portal B. You can implement so that can be authenticated across multiple sub-domains, but that's a non-default scenario and only applies to sub-domains, not to entirely different domains. In fact, prove it to yourself by logging into one of your portals and seeing the authentication ticket in your cookie collection. Then go to another domain/portal and view your cookie collection: your auth cookie won't be there (applies to any cookie).
I've implemented scenarios like this many times without issues (one app, many different "sites" with caching/differing views/etc.) albeit Forms Authentication ones, but the principal still applies.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 4 years ago.
Improve this question
i have register page in ionic that communicating with wordpress rest api, for register new user by api it needs admin access
for admin access i should post admin user and pass then by admin revised token send registration user request
but i want ask about secure of this method, when sending admin user pass through the app can it sniffed ?
i think in this method admin user pass can easily sniff
i'm not test it but i'm not sure about security sending admin data
please guide about it
Ionic is a client-side framework. Anything stored on or sent from/to the client is known to the user, and you can do nothing about this apart from making it somewhat harder. The user can be assumed to have full control of the client device, be it a pc, a mobile phone or whatever else.
So for you design to work and based on your description, you have to store the Wordpress admin username and password on the client. This is clearly insecure, your users will be able to extract it from the Ionic app itself, or even easier, when it gets sent to the server, as you correctly discovered.
The solution is to have a server-side component that will hold the Wordpress credentials for you, and your Ionic app would talk to your server only. This would effectively mitigate the Wordpress admin credentials issue, but you need another server.
Also note that using such a server, anybody will still be able to act like your Ionic app, and register users in Wordpress. You should not assume that it's only your Ionic client that can do this, because as stated above, anything known to the client is known to the user, who can create arbitrary requests, indistinguishable from your Ionic client requests. But with this new server in the design, at least the Wordpress admin credentials will not be disclosed, and any functionality not exposed by your server will not be available to endusers.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I am just investigating the issue and get many different suggestions, can someone be helpful in detailing the subject include
existing methods
restrictions
pros and cons
protection against attacks
I look for a short review to get direction.
EDIT:
The audience are user from world-wide that need to register.
Throwing in an answer here from some of the systems I have had professional experience with:
Note: I can further define positive/negatives if you answer the question I put in the comments about the parameters around your application.
ASP.NET Identity
Basic MS user system that ships with MVC framework that uses username and password. A plus side to this is that the concept has been around for a long time and there are tons of tutorials showing you how to extend it to use things such as email/password or collect certain data from your users like their mother's dogs middle name or whatever. You also would want to look here if you have an environment where users could possibly share computers. Think factory or hospital setting kinda deal. A negative to this is that you are basically forced to maintain the entire user setup, application roles, user management all contained within your application (or cluster of applications). Think Forms auth when it comes to this. You may want to look at this if your application is external and exposing AD services makes your security team uncomfortable.
Windows Auth.
You are basically authenticating against the Windows user account and although not necessary, for the most part you would treat something such as Active directory for your role provider. The plus side to this is that your application is really no longer responsible for user management and all the support that comes along with it (weeeeee!) but instead you are more authorizing roles to work within your application. This makes it a breeze BUT a huge downfall is if you have users that may possibly share computers then this is a huge security nightmare. You would want to target users who have their own specific computer where they come to work and sit with this one. This becomes a nightmare if your application is externally hosted as it is easy to make your AD vulnerable as some of its services will need to be accessed externally.
Forms/Windows hybrid model
In this you basically configure your site to run on forms auth BUT your forms auth system is set to auth users in AD as a background process. So this is more for when you have a mix of users where some are sharing computers and some have dedicated computers. You are basically setting up your own forms auth website that takes in a redirect url along with the user's user AD name and password. The forms auth website then checks if the users credentials are valid in Active Directory, sets fun things like a session cookie and redirects the user back to your MVC site(s) with an authenticated user. On your MVC site(s) you have AD connectors as well (or you could have a N tier design to look it up) to tell you what AD groups the user belongs to and handle appropriately. So plus to systems like this is that you take the user management aspect away from your single site and place that responsibility back into AD but at the same time you have the flexibility to launch application that are basically windows auth into environments that have mixed user (people with dedicated comps and those who share.) Downside to this is that initial first time setup is a massive pain because you are essentially building out multiple systems. Also, security is also a concern with this as anytime you have a shared computer environment things are more susceptible to abuse. You have to some up with a good session timeout policy and live and die by that. Also you can place your forms with site in the DMZ and separate external hosted applications from directly interacting with AD. A minus though is you will need to handle things like AD lockouts, password reset, brute force attempts and such.
External provider such as facebook, twitter, google with something like OAuth.
I have never personally gone down this path on a production application so I cannot give you the real world positive or negatives but it needs to be mentioned and maybe someone else can give us some insight there.
Apologies on the massive textblocks in this answer, will make the format a bit "prettier" when I can get to a desktop.
If you use the ASP.NET MVC Framework you can authenticate users with ASP.NET Identity or with an external provider(Google, Facebook, Microsoft, etc).
In Visual Studio, if you create a new ASP.NET MVC project and choose to authenticate using individual accounts, it will setup the Identity system for you.
And To keep users authenticated, I usually add the [Authorize] attribute above the controller class that I want to restrict access to.
I don't know it might helpful or not -
But we use signalR to see whether the User is connected and authenticated to the server or not all the time while he is doing his work.
In instances where you have multiple clients and a central IdentityServer 4 instance which handles user auth/n, how would you go about managing user profiles from individual clients?
Current scenario:
user clicks on manage profile
user is redirected to a custom manage claims page on IdentityServer which a) loads all claims in a form, b) allows user to mod such claims and c) updates them with new values
user is redirected to the referrer URL (which then retrieves
these fresh claims via a token refresh which includes the profile
scope) - although a redirect is not always possible, or is frowned
upon from a design perspective (users' experience is broken since
they are taken to a different location with a different design).
Desired scenario:
user clicks on manage profile
user is redirected to a profile page on the client itself (e.g. SPA or desktop), populated with info from the profile scope
user updates profile data, and client then makes an API call to IdentityServer to update the users' claims centrally
local claims are refreshed to reflect claims sent to Identity Server
Main concern: is this a sound approach architecturally speaking? Should user profiles (e.g. first/last name, gender, DoB, etc...) be managed by IdentityServer (via an API or own pages) or should these be stored centrally and used/managed by both IdentityServer (loaded as claims) and individual client apps? How would you go about tackling the desired scenario?
The closest info I got was in method 3 discussed here.
... however it's a 3+ year old doc, and am not sure what is recommended by oidc-client/IdentityServer 4 devs today.
Any insights would be highly appreciated.
Chris
I believe the main reason for the need of the second scenario could possibly be
taken to a different location with different design
Is it?
If it's not, I don't see any benefit from repeating the same or similar claim update page on multiple client apps, if there are more than one.
If it is and you can't customize the page on your identity provider (the Identity Server), you can still have a single claim update page but just hosted outside of the Identity Server. This page (formally: the app that hosts it) would be the client of the identity provider as well as the client app that redirects here.
A benefit of this approach is that you could have a total control of how this page looks like, event make it conditional depending on the client.
Should user profiles (e.g. first/last name, gender, DoB, etc...) be managed by IdentityServer (via an API or own pages) or should these be stored centrally and used/managed by both IdentityServe
There is no single answer to this as it totally depends on you actual business background.
It's even worse than you describe, you can have a hybrid system where some claims are shared by multiple subsystems but other subsystems have their own profiles not shared with any other subsystems and all these are integrated around one identity provider.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have an already built Asp.Net application which is using Asp.Net membership provider.
There is a client web application which has its own login. Once logged in, the user gets some links. These links are directed to the application I have developed. Currently since these are two different applications hosted in two domains, there are two time login required.
What I am trying to achieve is have SSO and not have to login when the user is already logged in the client application. I have read through and seems its possible to have this done via a STS provider like ThinkTecture IdentityServer and utlising ADFS at our end.
Is this the best approach and if yes, I couldn't find much of documentation with respect to what are the updates I need to ask from the main application team to have it SSO enabled.
That might be possible with STS Provider or ADFS. What I would suggest is to have a web application only for authentication where in when user clicks on login on main website, you can redirect to authentication application, authenticates and create a token and then redirect back to main application along with token. Later, you can call any applications along with this token and check if user has permission to access this application or not. Token contains information such as authenticated user, permission, etc. I suppose you need to create custom http module to implement this.
If all applications are under one domain, it can be achieved by cookies.
I believe the easiest way is using Azure Active Directory to do that. Here's a few articles/information about that:
http://www.dotnetcurry.com/windows-azure/1123/secure-aspnet-mvc-azure-using-active-directory-signon
http://azure.microsoft.com/en-us/documentation/videos/overview-of-single-sign-on/
I believe the best approach would be to host an Identity Provider like ADFS or ThinkTecture somewhere else and then make both the Main application and your application a relying party of this Identity Provider.
Both applications would need to be changed to support the WS-Federation protocol (which asp.net already has a HTTP module for supporting it).
Have a read of this https://msdn.microsoft.com/en-gb/library/bb498017.aspx
Then also check out this blog http://chris.59north.com/post/Configuring-an-ASPNET-site-to-use-WS-Federation
How about mimicking the SSO concept?
On click of the link provided in Party A's website generate a token
with a Timestamp.
Upload it in your DB through Services
Encrypt the token using RSA with additional parameters both agree upon
Redirect to your URL with this encrypted parameter converted to base64
Decrypt on your side and check for the token in your website and then allow to your website.
Write a logic for the token to be defunct in a specified time.
I am creating a project which has a login portal with multiple applications and websites. I want to allow the user to login and then click any application and have access to it. Some considerations are: each application is defined in a user profile, ie which users can see what. also each application privileges are different for each user. so user a may be an administrator of application a but just a normal users in application b.
What i know.
I can have one auth cookie created in the main portal which with setting the machine key and same authcookie name, each application can use it. I have done a test with this and it seems to work.
My problem
As each site/ virtual directory has different privileges per user and per application when the user access a site i need to get his privileges from the databases but I cant then overwrite the auth cookie userdata with the new details because he may have multiple tabs etc open at a time on different sites. So how can i have an extra cookie store per user and per application for holding application specific details. I know I could go to the database each time but that's allot of overhead for each post back.
Maybe another option is to use the main authcooke for checking the user is logged in then have a new auth cookie per aplication and user, but how can i have 2 authcookies, that may get confusing and the second needs to timeout when the main one does et c i think
Any help suggestions would be gratefully appreciated
THanks
------------------- EDIT -----------------------------
we have one user table for all all sites not 1 per each site. then we map the user to an application and then the user application and role. so when you get to an application it has to check if the user has access and what there role is. all other user details are already in the auth cookie when loggedinto the main site. We do it this way because we have to manage users in one application not each application. Hope this helps understand my requirements.
What you are describing is a 'classic' SSO (single sign-on) example. There are lots of ways people have tried this and they are well documented on Google.
One way to do this is to have your SSO server (e.g. the first place you land and log in) to issue a security 'token' (e.g. a Guid) and then either store this in a cookie or append to URLs. Each subsequent call to an application can look-up the token in a database, verify it's validity and carry on (or boot the user out if invalid).
Using a database also allows you to set a timeout for all applications for which the token is valid.
This can then be extended to allow the database to store which apps each user can access etc. I've described this in very broad terms but it may be a good starting point.
Hope this helps
BTW: querying the database on each request isn't too much of an overhead. I have applications that do just that and are still performant when loaded with 300+ users.