Yes, only from our own servers *for certain users*.

The situation is as follows: We offer a course administration service, online software for people/businesses who give courses, these include universities, businesses who train their own personel, etc.
Our course administration is only accessible to the trainers, the trainees get access to their track record using the DNN server. Accounts on that DNN server are created by the course administration software using a web service. That web service should best only be allowed from our server.

Also: Most clients allow their students to log in from anywhere in the world. Some clients want to display certain information -like allowing a student to apply for a course- only when at their own location, the campus network. Our servers are not at that location.

It would be great if these things could be configured using the roles. There is a fine-grained control over what user/role may acess which pages/modules, but that's only based on the user account, not on other properties, like ip-address, country of origin, device type, time of day, language, profile property, activity level or whatever you can think of on which you could create different behaviour. I know a webshop which is closed on sundays because of its owners beliefs. If isSunday could be a role, a content editor could create that behaviour.
IMHO the isMobile property available to module programmers could also easily be a role, making it available to content editors. And sure, in my web service I can check the ip-address myself, but again, this could have been a role making configuration much easier and general purpose.

As a more general DNN use case, I can imagine there exist websites who would like their content editors only to be able to access the site while at the office (or on the company VPN) while visitors may always access the site. I think this is the (only?) use case for the recently added ip-filter setting, with the limitation that visitor can never have an account (no forum, no comments, no (persistent) shopping cart).

I really don't understand why there are security roles, but admin/host users are a whole different kind of users instead of regular users with an admin/host role. Why has the ip-filter been created as a whole different setting, instead of a security role? It's almost a perfect example of a security role. But instead something has been created that's hardcoded to the logging in of (admin?) users.
It could have all been so much easier (both in usability and conceptually), more consistent, versatile and usefull, that I might have become a little bit frustrated about this ip-filter not being anything near what I had hoped for.

Ok, clear.
Your view seems to be from a situation where all portals are owned by the host. In such a view it can make sence to have multiple portals in one database (to share content?).
I'm looking at it from a perspective where a portal is owned by the customer and there is no reason to have multiple portals in one database, only reasons not to do that) . If one customer wants a password to be at least 10 characters long and very complex because his site contains sensitive information and is only accessisble to his own employees, while an other customer wants a password to be as simple as possible because it's just a blog and they want to make it as easy as possible to post comments, this should be possible.
I'm not saying you're wrong, but I am saying I don't agree with you. Or maybe not even that, but just that I have other views.
I'm not looking at the design of a CMS for a specific (type of) site, I'm looking at the design of a CMS that should allow anything. I don't care what the end user wants, I care that whatever an end user could want should be possible. I'm less looking at changes needed for practical use cases, more at generic concepts and what they could imply. And I'm not limited at all by legacy code, time or money. I understand that's a big difference. You might say I'm looking at it in a philisophical way, not limited by anything, as I'm not building DNN (who wouldn't want that job? ;)


As to the issue at hand, I to need to limit a limited group of users to a very predictive ip address. Unfortunatly the functionality created now does not concern 'a' group, but the very specific (and important) group of "any and all admins". It feels very hack-isch, I don't feel that the way it has been done has much potential, and although very near to what I want, not usefull for me at all. As soon as one portal owner requires to log in from anywhere, I have 3 choices : Tell him it can't be done (any user can, but the portal admin can't? that'll sell), disable the ip-filtering for all customers including the root admin, or set up a second server.

I have a hard time believing that "creating something and improving it if it becomes popular" is not a self-fulfilling phrophecy.

I'll create a "complete overhaul of the user/admin and permissions system"-idea in voice, let's see what happens. I'll be nice :)