Restricting users from directly accessing login.fcc

[Pradhap1125]

We have a requirement in which we have a custom login page which will call a java method and from java we we make a call to login .fcc with provided credentails .Everythin working fine as expected but when we enter the url of login.fcc directly from browser we can able to see the default login.fcc page which we don't want to have. So is there any configuration in policy server for web agent where we can restrict the access to login.fcc directly .

[malsi07]

Hi Pradhap,

Could you please explain the reason why you are entering the login.fcc url directly in the browser?

 

Thanks,

Shankar

[Pradhap1125]

Shankar, we are trying this scenario as part of security breach. Hence we dont want to expose login.fcc by any way, such as to make our application more secure.

[Legacy User]

This is a growing concern in the field. Especially hackers targeting login.fcc and constantly battering it with credential combinations.

 

OOB we can access login.fcc directly on a browser and it would display the page.

 

*** Depending upon usecases.

• If SecureURLs in ACO parameter is enabled, then we cannot access login.fcc directly on browser. The WebAgent will give a HTTP 500 error on the user's browser. Only 302 redirects to login page which contain the encrypted SMQUERYDATA will trigger the login.fcc.
  • It may suffice Internet facing usecases.
  • But If you are using logic on Internet facing portals to POST to login.fcc; that may not work once SecureURLs are enabled. I have not tested this, but based on the changes SecureURLs does, I don't think once SecureURLs are enabled, one can POST creds to that FCC.

 

 

We are also looking at options to mask the FCC using external capabilities.

[Ujwol]

I am guessing this should work. Just replace the login.fcc with empty page.

If I am not mistaken the lastest webagent code just looks for the existence of the file during post and the content in it doesn’t really matter if you are not using it for GET requests.

[Kaladhar Brahmanapally]

what is that latest version of webagent ?

what happens if username,password,target pameters are directly sent to that empty login.fcc page in post call  ?

[Ujwol]

It works. check out : Tech Tip : CA Single Sign-On :: Web Agent::How to restrict user from using login.fcc directly 

[Pradhap1125]

Thanks Ujwol, it worked for us

[Legacy User]

The real world challenge / use case is masking login.fcc OR protecting login.fcc. Even with a blank login.fcc hackers are exploiting it by posting credential combinations. What is there to stop some one from bombarding Username / Password even to a blanked out login.fcc.

 

Restricting means disallowing / securing.

 

SecureURLs to some extent does that job. I'll be spinning up a new thread in this regards.

 

Regards

Hubert

[Ujwol]

Even if you are able to secure login.fcc access completely, the hacker could still do the same to your custom login page.

 

Brute force login attack could be prevented in other ways. Like implementing smretries for e.g or temporarily locking out the user.

 

If your concern is DDOS attacks , then they can be prevented at webserver level.

 

Sent from my iPhone

[Pradhap1125]

Hi Ujwol,

 

Can we do curl post request to our login.fcc ?
if yes, can you give some sample requests.

 

I tried with below
curl -d 'USER="UIDOFUSER"&PASSWORD="PASSWORDOFUSER"&target="PROTECTEDURLHTTPS"' FQDN/siteminderagent/forms/login.fcc" -k

 

But getting Internal Server 500 Error.

[Ujwol]

Please open a new thread for new question which is unrelated to original topic.