Muhamad Hamza:
I have developed a custom login portlet...
In more than 95% of the cases I've seen, this is where your problem started. Login and identity management is (almost) fully solved and the reason you're going with a portal is that you don't want to take care of such infrastructure task. Even if you are one of the remaining 5%, where it makes sense to have a custom login procedure, I want this statement out here for others that come by later and read the article.
Make good use of your time and knowledge:
Implement business specific functionality,
use the underlying and available infrastructure. If you have specific login issues, changes are that they're long solved if you're looking at any of the available SSO solutions.
Muhamad Hamza:
... session.enable.phishing.protection=false property. Will there be any security issue if I add this property?
This is a feature that (to my knowledge) provides you with a new session once you're logged in. The critical point is: If you get your session cookie when you access the site through http (unencrypted) and then continue to use it on https, you might have your password protected, but anybody who has seen your session identifier while it was not yet encrypted, will now be able to continue to use it fully authenticated: All you need to know to take over a session is a user's session identifier. Disabling phishing protection
might be safe (keyword here is "might") if you absolutely do not have any unencrypted communication to your portal.
