I have an IIS website on a server internal to my domain that is also published via azure application proxy, which is secured using windows authentication. Our AD structure is hosted locally and published to Azure AD via AD connect.
Users visiting from outside the domain are authenticated first via the login.microsoftonline.com page.
My problem is that users external to the domain are on shared devices and need to change users occasionally, and I can't figure out how to do that.
I have read that navigating to an url like https://login.microsoftonline.com/{tenant id}/oauth2/logout?client_id={client id}&post_logout_redirect_uri={???} is supposed to achieve this, but after arriving at the login page and logging in as a different user, when we return to the site the user turns out not to be the user that authenticated, but remains the same user as before the attempt to change the user.
I have also read that deleting the cookies named like AzureAppProxyUserSessionCookie, AzureAppProxyAnalyticCookie and AzureAppProxyAccessCookie can help, but doing so does not seem to make any difference.
I thought that perhaps the browser was auto-authenticating or pre filling in forms etc, but turning those features off does not affect anything.
My questions are:
Are any log-off / log-on via Azure AD event logs kept that I can view, and if so, where?
How are you meant to log-off for my scenario?
Related
I have developed a web application written in just pure HTML.
<html>
My code goes here
</html>
And I have deployed it to MS Azure. I'm now looking for a way to authenticate this web application with Active Directory so only my organisation's employees can access it.
I have done tons of research online and it seems like there are many ways to do this. However, I'm looking to do it by "adfs/ls/wia" (correct me if I'm wrong).
The reason why I would like to do it only in that way is because:
I'm going to embed this web application into a dashboard.
In order to view that dashboard, users (employees) need to go to a specific website:
https://<dashboard>.<myorganisation>.com
And then users will be redirected to a sign-in page with this address:
https://fs.<myorganisation>.com/adfs/ls/wia
After signing in (with users' active directory accounts), users will be redirected back to the dashboard's website. The URL is now looking like the following:
https://<dashboard>.<myorganisation>.com/#/site?:isFromSaml=y
And then users can freely browse the dashboards (without having to sign in again) until they close their browsers. So I guess some sort of tokens/sessions are being kept.
My question is:
I would like to authenticate my web application with the same way and since it's only accessed after users have signed in, how do I by-pass this authentication step? What do it need to put on top of my HTML code or is there a way to configure this in MS Azure already?
Thank you so much!
The easiest way is to have two Relying Party in ADFS - one for dashboard - one for web application.
Then you will get SSO across them.
I have one Node Bluemix application configured with the SSO Service & connected with a Cloud Directory. I can successfully authenticate the user but I'm having problems to accomplish a successful logout. I have tried req.session.destroy, req.logout, and express-passport-logout module to end the session. But none of them worked. I also tried to remove cookies from my application but it didn't work as well. The only way it is working is by restarting the browser or clearing cookies from browser. Does anybody know how to achieve a SSO logout from the application?
The last time I used the service this was not possible. The problem is: what you are doing with the listed commands is to close your application session, not the one on SSO service. So when the user comes back (with the same cookie) your application will ask SSO service to check and it will accept the user (since the session there is still open). Currently there is no API available to close the session on the SSO service instance.
Actually, this becomes more complex when you use external IdP: even if you close the session at the SSO server, the browser will still have a session with the real IdP the user logged in from, which depending on the configuration of your service instance could be one or more of IBM, Facebook, Google, Linkedin. Some of these IdP's provide long-lived sessions via persistent cookies and your application can't force the termination on their side. That means that on next click of the "login" button, particularly in the case where the SSO service instance is configured to use only one IdP, SSO will happen seamlessly with no further interaction.
Take a look here to get more information.
As Umberto says, maybe it was not possible before, but now it seems to be:
Check this. You can redirect your user to this:
/idaas/mtfim/sps/idaas/logout
At least this seems to work if you only use Cloud Directory.
I've been reading for the last hour but it's still not clear for me how to automatically authenticate the current windows user in my node js application.
On my office PC, I'm already authenticated with my AD user when I access our company portal in Chrome (as it was added as a trusted sites). So the main question for me is what do I have to do to automatically detect/authenticate the user in my nodejs app if I add my site to the trusted sites? I'm pretty sure the browser must do half of the job as it probably sends some kind of data (hash) in the request, based on which the application must authenticate the user. I suspect this is the "www-authenticate: negotiate" header as I noticed this sends a hash in the request when I access the portal.
So far, the only tracks I'm still investigating are:
https://gist.github.com/charlesdaniel/1686663
But it's still not very clear for me how this automatic authentication works and what are the leads I should follow next. The entire process is still unclear to me
I appreciate any advices on this or at least a mid-level explanation on what happens behind the scenes when I access a page in Chrome and it automatically authenticates me. Thanks
I want to create a web page, that will serve to authenticate users based on credentials I give them (user1, pswd1 etc).
Only after a user authenticated, he should have access to a few other web sites,
on different folders of the web server, but which have no server side code(otherwise it would be simple.)
The user should be allowed access to the other sites, e.g. based on his IP,
for 24 hours or another period, or while he has the authentication site open on his browser.
The purpose if that the user will not have to enter credentials on each site,
and will enter his credentials only once, or once a day.
Restrictions:
I don't want to modify the target web site javascript code at all, e.g. to query a web service.
The user should be granted access using any browser,
so I assume I cannot use cookies.
If I would develop such a mechanism on Apache,I could, for example, have the authentication site PHP code add a line "Allow from ip" to the htaccess file of each target web folder, whenever a user authenticated successfully.
The issue is that I don't want to develop it as I am sure a solution already exists, and also I need a similar mechanism for both Apache and node.js (although i can live with two different solutions)
What information does the user have to identify themselves? How do you guarantee the user is who they say they are?
The whole point of authentication is to establish the user is who they say they are and that may create a session so that users need not reauthenticate.
If you want the user to authenticate in a single location and then reuse that "session" or set of credentials elsewhere, what you are looking for is single-sign-on / identity federation.
For instance, take airbnb.com. I do not need to authenticate there. All I have to do is authenticate with a third-party e.g. Google or Facebook. As a matter of fact, SO works in the same way.
One of the standards behind this technique is called Open ID Connect. Look into that. If you are willing to dish out money, you can look into commercial solutions e.g. Ping Identity. There is an open source implementation provided by Mitre / the MIT. It's available here.
In fact it occurs to me I can use simple routing.
In the top level folder have php code that does the authentication.
If the user is authenticated, route/redirect to the requested target site,
based on the requested url.
The url should be for example http://mysite/site1, where the authentication code is in the folder mysite, and site1 is not directly accessible.
Perhaps I can use something like php-express to reuse the same php code on node.js.
We are developing a Intranet portal that uses integrated authentication, but a few sections of the site will be exposed to users who are not in the domain. For those users we plan to use anonymous access. However, our display logic for the entire application is based on the user logged into the portal, so we are not fully comfortable with this approach. The URL has to be same for both types of users and transitioning between both the environments has to be seamless.
We tried using user controls in pages to authenticate but things didnt pan out. When the page is reached the standard windows authentication grey box pops up.
Is there any way to intercept the request at the IIS level like an HTTP application?
If applicable we would disable anonymous access and for unauthenticated users we will impersonate with a least privileged domain account and redirect to the home page.
SharePoint isn't really designed for the scenario you describe of mixing types of authentication. It dedicates a web application to one type of authentication. You can then 'extend' that web application to use another type of authentication on another address. For example, your intranet portal would use Windows authentication. It could then be extended to use anonymous authentication on another port or domain name.
One option for what you describe is to configure two separate web applications. One is for users that need to authenticate. The other is for anonymous access. Configure the content in the appropriate locations and link between the two as necessary. Users within your domain should not receive a login prompt when connecting to the authenticated site if you use this approach. Users outside your domain will receive a login box and won't be able to access.
Consider using forms authentication for users outside your domain if they need to access your intranet. (Once again the 'forms authenticated' part of your site would be extended to a unique domain name or port.) This would mean they will be prompted to enter their credentials in a form on the page when first connecting.
Read more about authentication on the Authentication Resource Center.
A couple of final points... If you can use SharePoint's default authentication mechanisms rather than writing your own controls, use them as they are well tested and secure. Also, don't be tempted to change SharePoint's IIS settings unless you are certain there is no other way to do what you need. SharePoint regularly updates these itself and may overwrite your changes (or give you grief in other ways).