Regarding the cursor, see
Nobody says anything on what the cursor "should look like" - that's up to the implementor to decide (the cursor is handed to the Provider's advance, hasCurrent, etc. methods).

The motivation behind the cursor is that the list of users can be arbitrarily large and may not fit inside of memory. Therefore, the security provider needs to read in chunks of users at a time, and needs to have a way to refer to this list. Iterator pattern.

Take, for example, 100K users stored in a db. Can't read them all into memory. Can read in chunks of 1K users in arrays, and use the cursor to contain the index into the array, and the name of the last user in the array. E.g, to start things off,
select USER from USERS where ROWNUM < 1000
and then, when you finish the first 1000 users off, do
select USER from USERS where USER > ? and ROWNUM < 1000
the ? in this case would be the name of the last user read off in the previous query.

By the way, there is no need to implement the User/GroupReader APIs. If you don't want to implement them, drop them from the "Implements" list of the MBeanType element.