I need some clarifications about multi-domain authentication. I have a site, e.g. www.example.com, which uses sys_folder id = 25 which has own users and groups. And now I created another domain using site configuration, www.example.com/mycompany, which uses another sys_folder id = 50. Both have felogin with different storage folders. It is correctly working in login failures. But when I logged in my main website, say www.example.com. It automatically logged-in on other domain www.example.com/mycompany, which shows my fe_users details. How could I handle authentication separately for domain-wise? Does TYPO3 support that?
This is a general issue and not really related to TYPO3: when you log in to www.example.com, the cookie path will be /. It cannot be anything else since it would then be limited to that path.
Thus when you enter a sub-site like www.example.com/mycompany, the cookie of www.example.com is sent since /mycompany is covered by the / path. See Set-Cookie: Wildcard "Path" for details.
The proper solution here can only be to separate sites using subdomains instead, e.g. mycompany.example.com and www.example.com. Then each site will have its domain stored in the cookie which ensures only the correct cookie per site is used.
Notice that in this case the main site must be something like www.example.com and not just example.com, otherwise the same issue will show up: a login cookie created on example.com will be sent for mycompany.example.com and all other subdomains.
Related
Good afternoon, how can I set up sso authorization from keycloak in my directus application? Below I will give the settings for my directus image. And the error that occurs when trying to log into the account.
So I ran into this the other day and redirect_uri is picked up from the PUBLIC_URL environment variable, which should be set as well. So you may wish to ensure this is set. You may also want to consider making your root url and base url simply http://localhost:8055 and making /* your valid redirect url, and narrow it down from there.
I have been reading a lot on Single Sign on and OpenId
I have checked the documentation for OpenId and Single Sign On on the below Link
Single Sign On
http://rashidi.zin.my/geek-talks/2009/06/30/php-mysql-curl-single-sign-on-with-multiple-domains.html
http://www.opengroup.org/security/sso/sso_intro.htm
http://www.authenticationworld.com/Single-Sign-On-Authentication/
http://merbist.com/2012/04/04/building-and-implementing-a-single-sign-on-solution/
https://wiki.queensu.ca/display/itsd/Single+Sign-On
https://github.com/jasny/sso#readme
https://lw.microstrategy.com/msdz/MSDL/940/docs/mergedProjects/websdk/topics/sso/SSO_Single_Sign-on.htm
OpenId
http://openidexplained.com/
http://openid.net/pres/protocolflow-1.1.png -- Flow Diagram
http://wiki.openid.net/w/page/12995226/Run%20your%20own%20identity%20server
Simple concept what i understood on Single Sign on can be explained as below
User hits domain1.com.
domain1.com sees there's no session cookie.
domain1.com redirects to sso.com
sso.com presents login page, and take credentials
sso.com sets session cookie for the user
sso.com then redirects back to domain1 to a special url (like domain1.com/ssologin)
the ssologin URL contains a parameter that is basically "signed" by the sso.com. It could be as simple as a base64 of encrypting the loginid using a shared secret key.
domain1.com takes the encrypted token, decrypts it, uses the new login id to log in the user.
domain1 sets the session cookie for the user.
Now, the next case.
User hits domain2.com, which follows domain1 and redirects to sso.com
sso.com already has a cookie for the user, so does not present the login page
sso.com redirects back to domain2.com with the encrypted information
domain2.com logs in the user.
OpenId Concept what I got can be explained as
OpenID allows you to use an existing account to sign in to multiple websites, without needing to create new passwords.
An OpenID is a way of identifying yourself no matter which web site you visit.
Now My problem is even after reading a lot of documentation, am not sure will i be able to achieve single sign on using openID and this is very important for me to know before i start my code.
Is there any way where i can upload my database to OpenId for Authentication, So my users do not need to go through all the drill again.
I will really appreciate if anyone has implemented this earlier or has any reference for me to make this clear
Yes, OpenID will give you single signon across web applications that may live in different domains. Note that OpenID 2.0 (which is the subject of the links that you point to) was deprecated and followed up by OpenID Connect, see: http://openid.net/specs/openid-connect-core-1_0.html#Introduction
There are a number of product and libraries that you can use to build on:
http://openid.net/developers/libraries/
As a more broad question I would like to ask what is the current best strategy for securing a website login. I know all of the basics, like salting a password, hashing the password, and using SSL to encrypt the transmission, but I feel that may not always be enough. What are the best, "hack-proof" methods out there?
Your points are already the most important ones, additionally you can do this:
Use a slow key derivation function like BCrypt to hash the password.
Add the X-Frame-Options to the HTTP header of your login page, so that the page cannot be shown inside an iframe. This can help against clickjacking. In PHP this would look like that: header('X-Frame-Options: DENY');.
Add the Content-Security-Policy to the HTTP header of your login page. If a browser supports CSP, this can be an effective protection against Cross-Site-Scripting. In PHP it would look like this: header("X-Content-Security-Policy: allow 'self'");.
Regenerate the session id on the login page, to make session fixation more difficult.
Use HTTPS for the whole site, this avoids lots of problems. If you need to switch between HTTPS and HTTP, then use a separate cookie for authentication, have a look at this example.
Should your site be HTTPS only, then you can add the HTTP Strict Transport Security header. The HSTS can prevent users (that already visited your site once), from calling unsecure HTTP pages. This can help against SSL-strip.
Don't store password at all, but use SRP
http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol
We have a Portlet running on Java/J2EE technology. It interacts with another application/system through HTTP request that requires user authentication. The current solution retrieves logged in user's user name and password from the Portal, and passes this information to back end systems using "HTTPClient" API's to retrieve content based on user's authentication and authorization.
There are efforts to enable site minder for the Portal. With site minder enablement, the Portal no longer provides logged in user's user name and password. The ideal way would be that back end application also has site minder enabled so that Portlet could pass the login token or cookie value.
Looking for interim approaches until the back end application is SiteMinder enabled. Is there a way we can enable/force user to enter user name and password ? I cannot think of such possibility because the Portlet code (using HTTP Client accesses the back end URL of the application, its not the browser). One possible way I can think of is, develop a new screen(UI) to have user enter user name and password within the Portlet and use that to authenticate with back end system through Java code. Please let me know if any other ideas.
Also, let me know if the question is confusing, I will provide more details.
Thanks
Siteminder can provide user information dynamically to connected applications in HTTP headers (uid, email address, etc.). This behaviour is configured on the Siteminder Policy Server. By default, the HTTP header SM_USER (or similar) contains the username of the authenticated user.
Then, you have to adapt your portlet code to fetch those headers from the request and feed it to the back-end application like you used to.
I wouldn't advise the use of the SM_USER header for tracking users. SM_USER contains the ID that was provided to the credential collector, and will change based on the type of authentication scheme used.
Example:
If you have an HTML forms based auth scheme that collects email address instead of UserID, the email address will be sent in the SM_USER header. In the case of an X.509 auth scheme the SubjectDN from the certificate will be in the SM_USER header.
The better choice would be to use the SM_UNIVERSALID header as that will always contain the Universal ID attribute. The Universal ID attribute is configured in the User Directory object (typically this is set to "uid").
How can I implement a cookie based single sign on without a sso server?
I would to share the user logged in across multiple applications using
only a cookie on the browser.
In my mind it's working like this:
user logs in an application
the application verifies the credentials and then it setting up a cookie on
the browser storing the username (that could be coded with a private key)
if the user opens another application, it searches the cookie and reads
the username on the value (using the key for decode the string)
In this solution a user may see the browser cookie (of a another user)
and take the string codified of the username. Then he could adding it on
an own cookie (no good!).
There's some secure way to do this? With a timestamp based control or
something like this?
Thanks in advance.
Bye
P.S.
I know that my english isn't very well.. sorry for this!
This is impossible. Cookies are unique to each domain, and one domain cannot read another domain's cookies.
I think the answer comes a little late, but maybe I can help someone.
You can have a cookie / localStorage in an intermediate domain connected to the home page using an iframe
1) Login
The login form in any of your domains deposits the identification token in a cookie on sso.domain.com by an event (postMessage)
2) Verification
domain1 and domain2 include a iframe pointing to sso.domain.com, which reads the token and notifies the home page
To simplify development, we have released recently a cross domain SSO with JWT at https://github.com/Aralink/ssojwt
There is a simple solution without using an sso server, but not with 1 common cookie, as we know that cookie's are not shared between domains.
When the user authenticates on site-a.com, you set a cookie on site-a.com domain. Then on site-b.com, you link a dynamic javascript from site-a.com, generated by server side script (php, etc) who has access to the created cookie, and then copy the same cookie on site-b.com on the client-side using js. Now both sites have the same cookie, without the need of asking the user to re-login.
You may encrypt/encode the cookie value using a method that both site-a and site-b knows how to decode, so that site-b will be able to validate his cookie copy. Use a common shared secret that without it will be impossible to encode or decode.
You see that on the 1st page load of site-b.com, the cookie is not present, therefore if you see necessary, you may want to do a page reload after setting the cookie.
I have done something similar. There is a PHP application where the user logs in, the system contact a web service and then the service checks the user's credentials on the Active Directory. When the user is authenticated, his PHP session is stored in the DB. Another web application can read the PHP session from the cookies and uery a web service in the PHP applicaiton, the PHP application check the session in the database and return the user id. In this way I have a SSO using SOA.
Do not rely on the user id stored in the browser, is a security error, at least encrypt the id.
The best solution would be to put the login form and session storage in the same application, then this application can provide services to other applications.
And use HTTPS for the kind of infomation exchange.
The cookies can be read only if the belongs to the same domain, for instance:
intranet.example.com
crm.example.com
example.com/erp
You can access cookies across subdomains, but I do not think using browser cookies is a great solution. You really don't need a "SSO server" to implement a single sign-on. It is fairly easy to come up with a payload that both applications recognize. I have seen custom SSO solutions that transmit the payload using XML over HTTPS.
Here is a solution (which will hopefully get heavily scrutinized by security gurus on here):
Have each domain store user data in a similar cookie, and when a user want to jump from one domain to another without authenticating themselves on the new domain, provide a "jumplink" with an encrypted token in the query string. The new domain would decrypt the cookie, and figure out who the user is, then issue them a new cookie for that domain. You would want the "jumplink" to have a very short expiration date, so I would not generate them right into the page, but generate links to a "jumplink" generator and re-director.
This might not be necessary, but the receiving page for the "jumplink" could make a web service call back to the originating domain, to verify the authenticity of the encrypted token and the whether it's expired.
I think this solution would be susceptible to man-in-the-middle attacks (not sure if it would be more so than other auth mechanisms which are currently popular), but you could incorporate a client MAC address and IP address into the encrypted token for extra security.