Automatic redirection to the login page based on the loginUrl attribute only works if you are using simple declarative security in web.config using location and authorization elements and usually hard coding user names in web.config like in
this tutorial.
Declarative security while simpler is not compatible with a content management system where the "pages" come from the database and don't neccessarily exist on disk and where users and roles are coming from the database as well.
All pages in mojoPortal have permission for view and edit by roles so its not just a question of is the user logged in and re-directing to the login page. In mojoPortal permissions are checked in code and if the user is not logged in and also in a role with permission they are re-directed to the access denied page.
There is some redirection logic for after login but not when the access is denied. Whatever page you are on when you click the login link, is the page you will be returned to after you login. So for example I may be reading the forum but I can't reply because I'm not logged in, I click the login link and when I login I'm redirected back to the page in the forums where I was and now I can reply. This is the natural flow in mojoPortal, I could be on any page in the site and I don't see the edit links, I decide to edit so I need to login and it always takes me back to the page I want to edit.
Its just not a valid assumption in mojoPortal that Access denied is because the user is not logged in and no reason to assume if the user logs in that they will have permission to access the resource that produced the access denied error.
Hope it helps,
Joe