------------------(1)-------------------
With current approach you may have to extend your portlet with additional functionality, such as:
1. remembering whether your portel has already been approved by this user (is it going to be per portlet instance, per page or per portal ?)
2. adding sequence of approval screens if user has not signed up yet.
This approach is OK but but your portlet becomes very complex and expensive to maintain. And not much re-use can be achieved here.
-------------------(2)------------------
You may review your functional requirements and move permissions and access management up from portlet to group(e.g. community) level, such as:
1. create another community 'XXX', which would have this custom portlet deployed
2. organize navigation to this 'XXX' community from default community in such way that it is not displayed if user is not a member of it.
3. by default, users will not be members of XXX community
4. create independent (and resusable) community signup portlet (or use an existing community management process)
5. create signup page within default community and place this portlet there.
6. when user completes signup process, add 'XXX' community membership to the user
7. access to 'XXX' will become visible to this user, as per (2)
This way you may use a lot of existing out-of-box permissions management functionality, which for example may allow you to revoke access right by removing community membership from given user. Otherwise, you will have to extend your own portlet with all these and similar capabilities which are quite generic across the portal.
