When you change protocol, you will need to specify explicitly in your link target that you want the client redirected to
http://your.internal.site/somepage.html. Trying to do this via a link of the form
your.internal.site/somepage.html:80 will result in the user's browser trying to speak HTTPS over port 80, which is almost certainly not what you want.
As a secondary consideration, I hope you have some (relatively) secure way of passing along the fact that the user has actually signed in successfully; otherwise a user could just point his browser explicitly to the internal website, and connect without ever visiting your login site. Such a mechanism would have to pass along some sort of token that would be accepted by the internal web server as evidence of the login, but which was (extremely) hard for a user to forge.
The only scheme that comes to mind for this is a database on the login server that will verify
on each web access request that user
foo, represented by encrypted token
bar and originating at IP address
x.x.x.x , is a legitimate user. The encrypted login token can be passed back and forth between the client's browser and the internal server (and between that server and the login server), provided the encryption covers not only the password, but also the IP of the request and maybe the time of login. This login token can be created by the login server, and passed back to the browser, as well as being stored in the login server's database. That way, an eavesdropper would have a pretty hard time of it even if he obtained the encrypted token, since he would have to break the encryption, substitute his own IP, and re-encrypt before some reasonable timeout (say 15 minutes) had elapsed. Every time the login server is asked to validate a login token, then it should reset the timeout. If it ever receives an invalid token, it should invalidate any saved login data for the IP address from which it originated. You get the idea.
.
