TLDR: Which is the correct way to check for login states across multiple web pages, a SPA or a Web App.
I'm looking to develop an internal staff website for a company I'm working with. We currently have a SPA configured and developed and working properly but as we are adding more features I'm thinking that we are going to need more than one single page.
Correct me if I'm wrong, but this is my current understanding of MSAL.js with SPAs. Let's say a end-user is attempting to access our staff page at [company].com/home, if the user has not authenticated with their account that is stored in our Azure AD, the end-user can authenticate only for that page and their session state can be stored in the local storage, so when they access [company].com/home, their login can be acquired silently and the end-user will not have to log in again. If they do not have an account, they will not be able to access any page.
Also, by this logic, if the end-user accesses [company].com/staffresources, they will have to also login for this page as well, in addition to the cached login for [company].com/home, and the same will follow for each page throughout the website. At least, that is my understanding, correct?
I do see that there is an option for a Web App, would this solve the issue to where the end-user would have to authenticate each seperate page that they attempt to connect to? Or is there a way to check for a login state using a SPA, if the user has not been authenticated, they are can be redirected to a [company].com/login.
Any direct links to proper documentation for a solution would also be greatly appreciated.
localstorage is segmented by domain, not by each individual page. If a user signs in with msal.js on [company].com/login they will be signed on every page under the [company].com domain.
Related
I'm trying to create an admin portal for an already created application. Only owners should be able to authenticate through that particular page. The rest of the accounts in the firebase authentication shouldn't be redirected. I'm using React and Firebase. What are the potential solutions to that?
Firebase Authentication makes no distinction between where the user signs in from. No matter what place they use to sign in, they end up in the same state: as an identified user.
Your application code however can make a distinction based on its knowledge of the user. For example, if you have a list of application administrators somewhere, or have added a custom claim to the profile of application administrators, you can use that information in a so-called auth guard in your application's routing logic.
See some of these search results for more information about this, and questions like this one: How to restrict access to pages in next.js using firebase auth?.
I have a React Native app that authenticates users by displaying a WebView with a https://login.microsoftonline.com/common/oauth2/authorize? url. Right now the user has to enter their password whenever the app is not in memory anymore (I think that's it) which is quite often. I was thinking of a way to implement browser-like automatic sign-in. There are packages that allow for storing web cookies etc.
My question is (and it might be totally off, let me know):
What cookies should I store? Is it even cookies that are responsible for fore-mentioned type sign-in, if yes, can they be retrieved? Any and all suggestions are welcome
Thanks
What cookies should I store?
If you are looking the way to persiste
nt User Login.
The JWT accesstoken that got from Azure AD and userId etc. should be stored.
Is it even cookies that are responsible for fore-mentioned type sign-in, if yes, can they be retrieved?
You could get more information from React Native: Persistent User Login.
The example is related to store the Facebook login information, but the principle should be the same.
You also could get the demo code from github.
I'm developing a simple personal blog engine in MEAN stack using JWT as authentication method. I would like to implement a front-end admin panel page accessible only to Admin users. I have already implemented a simple role system where i can retrive the user's role both server side (in the db) and client side (saving the "role" property of the user in the jwt token).
Question is: how to implement a secure access to the admin page and maintain the single page application structure? I could simply implement that with angular ui-route, checking the role in jwt token, but an user could simply exploit that with local modification in the js scripts, accessing the admin page without authorization. Or i could implement that server side, serving the admin page only if the user has the right authorization; this is definitely safer, but so i will lose the single page structure because I have to send a different page.
Thanks in advance for any help/advice/answer you will give
I'm very new to LDAP and Active Directory and I'm probably understanding something completely wrong.
I know ASP.NET Identity and forms authentication (however, I'm also quite new to that) and my question is actually if it is possible to use certain features you can use with forms authentication (explanation further below) with Active Directory.
I'm building an MVC web application and I'd like to authenticate my users against Active Directory. That would be possible with ADFS. The template you get when using ASP.NET Identity in VS2013 uses passive authentication. Is it however possible to not do this redirect to the Active Directory domain but create a custom login page for the user?
Is it also possible to do user management with Active Directory like that is possible with forms authentication? I was thinking about:
A page where the user can register himself
Ability for the user to change his password (I know this is possible with ADFS, but the user may not be logged in. I want him to do this when he's logged in, with a self-made page.)
Logging in on a new computer should ask for a code specified in an email
Set up password policy in the application
... (Other things that I might have forgotten)
When these things aren't implicitly possible with Active Directory, please advise on how to configure the application to acquire this functionality (when possible with Active Directory).
Thank you very much in advance for helping me!
EDIT 1:
To leave my question not too open, I maybe better just start with that custom login page. When I understand it well, the normal flow when using ADFS to authenticate your users against is:
A user tries to access a web page of an application for which he needs to be authenticated
(Passive) redirect to a login page provided by ADFS -> user enter his AD credentials
ADFS returns token
Token is sent to the web application (that ADFS trusts)
When the web application thinks everything is ok, it stores an authentication cookie in the user's browser (I guess), and the user can access the web page
What I would like:
A user tries to access a web page of an application for which he needs to be authenticated
Redirect to a login page of that same web application where the user can enter his credentials
The entered credentials are sent to ADFS (I guess) and it returns something (a token?) with information about whether the login succeeded or not (This step could be preceded by a call to some (self-made) service (a Web API application) that multiple client applications could use for their authentication against the same directory)
When the login succeeded, the web application stores a cookie in the user's browser and the user is able to access the page
I don't know if that makes sense? I'm just wondering how companies that use Active Directory to store user information can still have a custom login page, registration page and other user management stuff. (Or don't they use AD but do they just have their own databases?)
Normally if you want a custom login page you use an ADFS active profile implementation (e.g. WCF) to do the authentication.
User provisioning is not part of ADFS. To do this you need an Identity Manager e.g. PingFederate, OpenIDM.
If you are using ADFS 2.0 or 2.1, you can customize the pages (because they run on IIS) and add these features or redirect to a separate website which does.
Most of what you want is OOTB AD functionality. Refer: Everything in Active Directory via C#.NET 3.5 (Using System.DirectoryServices.AccountManagement).
Password policy can be extremely complex. I don't know of any API's that explicitly do this.
If you are using ADFS 3.0, these is no ISS so you are pretty much out of luck.
It's not really an answer to my question here, but if someone is interested in what I eventually did: you can read it (very briefly) here.
I have two separate applications (app1 and app2 based on MEAN stack) running on my server. I want to add a new application that manages the authentication for both applications. I mean if I try to log in from app1, it redirects me to a login form in auth application, and after login I come back to the previous url in app1. After that, if I go to app2, I'm still logged in.
I'm looking to implement something like similar to the google accounts/ServiceLogin: I can log in one time, and the session remains for almost all google products.
Something important is that I use subdomains for each app: app1.mydomain.com and app2.mydomain.com.
How can I do that using node and express?
Currently I use vhost to manage each subdomain.
You're looking for a single sign on solution.
I'm only familiar with one solution that Stormpath provides, which is called 'ID site'. It's basically a hosted authentication site that handles auth for you, then passes logged in users between your subdomains.
The way it works is like this:
User visits www.yousite.com.
User clicks 'login'.
User is re-directed to login.yoursite.com.
User then logs in.
User is then redirected to dashboard.yoursite.com and is fully authenticated (SSO).
You can implement this quite easily using express-stormpath, here's the relevant docs: https://docs.stormpath.com/nodejs/express/product.html#use-hosted-login