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.
Related
In our project we've built an Azure Function which launches Puppeteer in headless mode, goes to our webpage and takes a screenshot of the page which is then emailed out as pdf report. Works locally and deployed to Azure. That was the POC though. Now, we're moving to production and introduced authentication (Azure AD B2C, single tenant), will run each http request via APIM etc.
What happens now:
our Function app was registered in AD as a daemon and receives an access token.
this access token is inserted into 'Bearer ' Authorization header in Puppeteer (page.setExtraHTTPHeaders)
headless browser does not get authenticated and screenshot we receive is of the login screen (Azure SSO)
What needs to happen
we need to convince the react-msal library our FrontEnd is using to authenticate users, that the headless browser should get authenticated and allowed to render the page
The solution I've come up with so far is to replicate msal-react's logic of saving session information into Puppeteer's session storage, so that when msal-react checks for persisted session it will find it and allow headless chromium in. I'm yet to implement it. I'm curious if anyone in the community has experience building something similar.
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?
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 have been working on IBM Maximo Anywhere apps such as Work Approval and Work Execution for sometime now have few queries regarding the login mechanism used by these apps. To be specific as per my understanding anyone having access to maximo on that particular environment can login into the anywhere apps - is that a correct statement? and if yes then how does it work in a disconnected state? If for any reason maximo is down will it mean that the app will not be able to authenticate a user and hence unable to login as well? And alongwith that is there any other kind of authentication done for example LDAP etc? Are there any different kinds of login failure messages that are displayed depending on why the app isnt able to let the user login? or is it a common one saying "Login Failed"
The first time the user ever logs into the application, they do have to have a connection to the Maximo server to authenticate. We also validate that the user is authorized to use this particular mobile app. We have a security group for each mobile app that the user must be a member of. After the authentication and authorization finishes, we download, store, and sign the locally stored data with the username/password combination, so that on subsequent login attempts, if the server is down, we can fail over to the locally stored data. This also guarantees that the locally stored data is protected.
We support all of the types of authentication configuration that base Maximo supports.
More information here:
http://www-01.ibm.com/support/knowledgecenter/SSPJLC_7.5.0/com.ibm.si.mpl.doc_7.5.0/security/c_authentication.html
I am developing a healthcare related web app and part of HIPPA compliance is that public available web apps need to enforce certain log-out behaviors. One such requirement is that when the users clicks "logout" in the app they must be logged out. Relying on the user to close the browser to clear session storage is not an option.
I am using ADAL-js with angular to handle auth for my app. When you log into the app login.microsoftonline.com stores cookies. As a result if you navigate back to the app you are auto logged back in without being prompted for credentials. That violate the requirement described above. If you use the dev tools in chrome to delete the cookies for that host the problem goes away.
Does anyone know of a way with the Azure AD Oauth service to enforce this more strict requirement?
We ended up opening a bug against Azure AD with Microsoft. They have since deployed a fix. This all occurred earlier this year. So this update is a bit late.
ADAL.js exposes a couple of functions clearCacheForResource() and clearCache() in the adalAuthenticationService Service. After calling adalAuthenticationService.logout(), you can clear the browser cache by calling the above functions. They should clear the cookies.
You can also try using the $cookieService provided AngularJS, for better control on the cookies.