I am developing a website using WIF-ADFS technology to achieve single sign on (SSO).
As such, the page will first automatically redirected to the ADFS Page, however the users will then need to input their ADFS Login Credential.
If ADFS-Login is successful, the page will then redirect back to my site with the claims.
The questions are:
Can I omit the ADFS-Login step? regardless of my device and my working network?
If yes, what response should I expect if the user is not recognized by ADFS? will there be no claims sent?
You can not omit the ADFS login step.
If everything is configured correctly in ADFS, IE and Chrome will likely do automatic logon. Firefox won't, Mobile devices won't and Linux machines won't also.
If a user is not authenticated ADFS will never send him back to your application. If a user accesses your application without being authenticated, he will be redirected (or the access will be denied).
Related
I have been tasked with integrating single-sign-on for an existing application, so I've been working on a couple of demos. The first one was the standard demo for Spring Security and I got that working. Now I'm trying to do a proof-of-concept demo where I created a toy version of the application in question with only two screens: one for login, and one to display some information about the user that logged in. I want to integrate SSO with this application so that the user has two ways to be authenticated: either by entering credentials directly in the login screen or by a SSO SAML request...
So I copied over SAML libraries and configurations from the standard SSO demo into my proof-of-concept application, and I seem to have SSO working, albeit a bit too well, in that I'm no longer able to get to my login screen, i.e., I still want that to be the default behaviour for someone entering the base URL for the application. How do I have to configure my application to achieve this?
The way I solved the problem was by changing the Spring Security configuration so that instead of using the generic /** to require SSO authentication for most pages of the application, it nows only requires such authentication for a single HTML page, sso.htm. This "page" is really translated by the application as a request to a controller that handles the application-specific processing for an SSO request. The initial page for the application, redirect.jsp, now contains some logic to pick which page a user should be redirected to, based on whether he or she got to that page directly (i.e., by typing in the default URL for the application) or via a SAML message from a trusted identity provider.
Note: For this to work, the initial page cannot be designated in the Spring Security configuration as either a secured or unsecured page. If it were secured, then this page could only be accessed after an SSO authentication, so a user would be thwarted from doing a non-SSO login. If unsecured, then the security context would not be accessible from that page, so the page logic would be unable to determine if the user in question has SAML credentials and an SSO authentication request for the application could never be fulfilled.
Once the user has been authenticated, either by credentials entered in the login screen or by an SSO request, from that point on, the application's continuing authentication of that user to view its pages is the same, i.e., no further SSO authentication is done. But when the user logs off from the application (or is logged off due to a session timeout), a check is made then to see if SSO authentication was done for this user. If so, then in addition to being logged out from the application, a local SSO logout is also done for the user, i.e., the SSO authentication session for the application is terminated, but the user remains logged in with his or her identity provider. So such a user could log back into the application in question, either directly via the application's login screen or by having the identity provider issue a new SAML message.
Hope this helps someone else...
I've a sub-application that I want to use windows authentication.
I want that login box pops up even in the domain when the person first reaches the page.
When I turn off Kernel-mode authentication, the login box pops up, but fails with error 401 Not Authorized after 3 login attempts.
If I turn this on, It doesn't even asks for the password,I believe this is due the computer is in the servers domain and the credentials are passed automatically.
Is there any possibility to show login form for all users, including domain users?
In the image below are my server configs.
Windows Authentication is normally handled by IIS. This is the way it works:
Client requests the page.
IIS returns a HTTP 401 response, with a header saying that it accepts Windows auth.
The client's browser automatically resends the request with the users credentials (as long as the site is trusted).
IIS verifies the user and passes the credentials to the application.
This is all designed to be seamless.
If you want the user to be prompted for credentials all the time, then either:
Make sure your site is not trusted (not in the Internet Options Trusted Sites or Intranet Sites). But you may not be able to do that.
Don't use Windows authentication. Uses Forms authentication and make a login page where the users can enter their credentials. But that means that you will have to verify the credentials against Windows or Active Directory yourself in your code.
If you use #2, then also make sure to use SSL on your site since passwords will be sent in plain text.
You can use Basic authentication. It will prompt the user for credentials and once entered, it will give you a seamless experience.
However, the disadvantage with basic auth is that it sends the password in plain text to the server. You can use SSL certificate to encrypt this information.
I have configured thinktexture identity server which is connected with my database for authentication and returning the claims in response.
Now I am able to use STS in my website. Behavious of STS is, user is getting redirect to STS website login page for authentication and response is getting retun to my website after successfull login.
I want to implement a little bit different. I want to use Login page from my website itself instead of using this from STS so that stsyle and theming can be displayed as per my website.
Also want to implement many other password control features ie Password expiry warning, force change password etc can be implemented within the website.Please suggest the approach
Look into the WS-Trust endpoints that IdentityServer supports.
After a lot RnD, we finally reach at conclusion that it cannot be achieved.
It will always redirect to identity server URL for authentication.
I have an ASP.NET site on a public web server, where users login using forms authentication.
I would like users within certain organisations to be able to login automatically through Windows authentication (bypassing the login page). However, because these clients are on lots of different servers, I can't just build in Windows security to the main site. (I know there are articles on how to mix Windows and Forms security.)
My idea is for each organisation to install a page onto their intranet which redirects to my website and authenticates the user according to their Windows domain and username. Is this possible to achieve securely? How could I go about doing it?
What you have described is almost federated identity.
As well as a page on each site, you will also need a webservice whch will validate a token.
Essentially the flow is:
User comes to your logon page
you redirect them to their company logon page
their company logon page takes their credentials and redirects back to you returning a token
you then call their webservice to validate the token an determine who the user is.
Many public API's use this scheme (facebook being a notable example).
look up oauth and federated identity for more information.
We have an internal web app running on IIS6 and we use the integrated windows authentication for domain users to login to the app before they can use it.
What we would like to do is redirect the user to an error page if they fail to login to the domain 3 times.
Where should i be looking to configure this? My first thought was in IIS, but i don't see anything in the config there that relates to what i'm looking to do.
How are the users authenticating? If they are using IE then domain authentication should be automatic (ie. the server does an NTLM challenge to the browser which is handled automatically by IE if the web server is in the intranet zone). In this case it would not be possible to fail to log in if the user is a member of the domain.
If you are using a login form which then then verifies the credentials against the domain controller, then you can implement a custom solution which counts the invalid logins and does a Response.Redirect to an error page.
Without knowing more about the setup it is difficult to answer more fully...
Personally, I'd make this database driven. assuming the user enters the username credentials correctly but fails to enter the correct password. When they do login correctly, set their FailLoginCount to 0, and eachtime they fail, increase it by one.
Once it reaches 3, redirect them to your desired page and possible "lock" their account.
HTH