I have recently started using the SAML Python toolkit (Flask) from OneLogin. I have a problem in that when I sign out of the application itself, it does not sign out of SSO so that the application can be re-entered into with existing login credentials stored in SSO. Is there anything that you can suggest I can look at to help solve the problem? Logging into the application is no problem, just when logging out, SSO still retains the details. Is there something in settings.json I need to do further?
I can force it to SSO to fully log out but only by force, it does not do it automatically.
What is the difference between singleLogoutService for the sp and singleLogoutService for the idp?
Any other aspects of the settings.json file that I can check over / alter?
Thank you in advance.
Andrew
I've wrestled with the same problem myself. From what I learned, its possible to setup a logout functionality which you can then add to your settings.json. However, this requires SAML2 to be configured in a certain way in addition to that if I recall correctly.
The solution I came up with for now is to have a logout page which deletes the session data via "request.session.delete()". However, in order for this to work, the user then has to completely close his/her browser afterwards. Therefore, this command is perhaps best displayed on a webpage that says something like, "You have been logged out, please completely close your browser to properly end your session."
Related
I’m a beginner engineer, all I want to know is how we can integrate biometric authentication to existing projects. I’m aware of the biometric authentication process and tried as an example and it worked out . Please show me a way to find this one. I’ve searched many websites related to this, but couldn’t find anything. I’m supposed to know how we can start with biometric login without prompting a biometric icon or something that is I need to login whenever I touch the sensor while the app is opening. And then after successfully login, how can we be redirected to the home page using the URL in android studio. Your time and efforts will be appreciated. Thank you
I've created a Bot in MS teams that can authenticate the user against AAD. I've used the AuthBot code for this.
This works correctly. I have questions regarding further improving the sign-in experience. The Bot currently opens up a web browser, the user logs in and is redirect to a page with a magic number that he or she needs to copy-paste back into teams.
If I understand the Authentication section on this page correctly, then the following should be possible:
The browser window can be opened inside of Teams instead of through
the browser by specifying a validDomains attribute in the Teams
package manifest file. However, I chat with the Bot 1:1 and it
doesnt seem to use the manifest file (the Bot's image doesnt use the
one from the manifest). How do I get the login window to open inside
Teams?
There is a MS Teams javascript file. Can I use this (on the page that my Bots shows after authentication) to
redirect the user back to teams, and possibly automatically paste
the magic number into the chat with the Bot?
We missed answering this in August, apologies.
A more elegant way of doing bot authentication has been a common developer request. We are almost ready to publish samples and documentation for this solution once it's fully deployed on all client platforms. This approach removes the need for AuthBot completely and supports an integrated authentication experience, i.e. without opening a browser tab.
Currently, however, to answer your question, there is no way to have an inline authentication experience and the validDomains is not enforced (since it's just opening a browser page). The JavaScript client SDK you refer to is not used at all with bots because bots cannot currently run code on the client.
So in other words, what you are doing with AuthBot is currently the best possible way to do it.
When I browse to Libspotify's application keys page, I'm asked to login. I do (with a premium account), and I'm tossed through a loop back to that first screen asking me to login again.
I need an application key (spotify_appkey.key) to get started, but it seems impossible. Anybody have any thoughts?
FYI Spotify has fixed the issue. Should now be able to generate keys as expected.
We updated our web site and service this morning and several users reported they couldn't log in. For each user we've looked at, the login has worked a short time after they reported it. We are looking to some type of caching as the possible culprit.
Is it possible that the "rememberme" setting during our servicestack authorization is causing a problem? Might we be picking up an old session that isn't working with the newly compiled servicestack service?
Any other ideas someone might have would be useful.
If it's an old session problem, you can verify that clearing the cookies cache from the client browser and refresh it.
I've created an intranet site that uses windows authentication
In chrome I can access the site instantly, and in FF it requires Active Directory login.
But with IE7 I'm getting the following error:
401 - Unauthorized: Access is denied due to invalid credentials.
You do not have permission to view this directory or page using the credentials that you supplied.
Im unsure as to why its okay in other browsers but not IE?
Any help appreciated.
Thanks
Solution:
IE is using Kerberos and not falling back on NTLM like Chrome and Firefox. You must force NTLM authentication in IIS7.5 by following these steps:
Select your site.
Double click authentication.
Select "Windows Authentication" (ensuring that it is enabled).
Click "Providers..." in the right hand column.
Select NTLM and click "Move Up".
Link: windows authentication not working in ie7
I'm not familiar with IIS, but in the past few weeks I've had lots of hand-on experience in integrating AD login into web applications. As is quite logical - every Microsoft product would be better integrated with another such, and Internet Explorer (should be valid for all versions, not just 7) automatically passes your AD login credentials as long as you use Active Directory for your Windows login authentication method.
Every other browser will either need to be configured to do so, ask you to type them in manually or will not support it at all. Which explains why Firefox asks you for a username and a password. Under Opera, you'll most likely get the same error message.
My guess about Chrome is that it's your default browser of choice and at some point in time, you've typed in your login creditenials and that session is still active.
All of this would mean (if my assumptions are correct) that you need to use a different AD account to login into this application than Windows and the latter (being automatically passed by IE) is not authorized.
It sounds like your environment is not setup properly for Kerberos authentication to take place. There are many things that can cause Kerberos authentication failure. E.g. Clock skew on the server or client, missing SPN on the web server, etc.
Normally, when you configure to use Windows authentication, you are asking to use SPNEGO, which means using Kerberos whenever possible and then fall back to NTLM if Kerberos fails. However, this post pointed out that this is no longer true. IE7 stops at Kerberos in certain cases but not falling back to NTLM.
You can try to disable the "Enable Integrated Windows Authentication" as the post suggested. It looks odd but it actually just turns off the SPNEGO, you will still use the NTLM.
I guess Firefox and Chrome works because they are using NTLM but not Kerberos. From my experience, non-Microsoft browser doesn't do Kerberos out-of-box. You need to do some configuration work to make it happens. For example, in FireFox, you need to set the network.negotiate-auth.trusted-uris parameter. See here
Once you confirm the NTLM for IE7 is still working fine. Then, you can post another question to ask how to fix the Kerberos authentication problem for IIS.
start off by looking here and getting a more detailed error description. I had some crazy problems with CRM and it all came down to the order of settings in IIS the answer to the problem ended up being as simple as ;
going into iis and then the authentication setting
clicking on windows authentication and selecting advanced
make sure kernel mode is on
click on providers and ensure negotiate is above NTLM.