1. Go to Shared Components / Plug-ins
2. Click “Create >”
3. Enter Name: APEX Group Authorization
4. Enter Internal Name: COM.MY-COMPANY.APEX.GROUP-AUTH
5. Enter Type: Authorization Scheme Type
6. Enter PL/SQL Code:

   function is_authorized (
       p_authorization in apex_plugin.t_authorization,
       p_plugin        in apex_plugin.t_plugin )
       return apex_plugin.t_authorization_exec_result
   is
       l_group  varchar2(4000) := p_authorization.attribute_01;
       l_count  number;
       l_result apex_plugin.t_authorization_exec_result;
   begin
       select count(*)
         into l_count
         from apex_workspace_group_users
        where user_name  = p_authorization.username
          and group_name = l_group;
   
       l_result.is_authorized := l_count > 0;
       return l_result;
   end is_authorized;

7. Enter Execution Function Name: is_authorized
8. Click “Create”
9. Click “Add Attribute”
10. Enter Label: Group Name
11. Enter Type: Text
12. Enter Required: Yes
13. Click “Create”

The plugin has been created. Now we define an authorization based on the plugin.

14.  Go to Shared Components / Authorization Schemes
15. Click “Create >”
16. Click “Next >”
17. Enter Name: Is Manager
18. Enter Scheme Type: APEX Group Authorization [Plug-in]
19. Enter Group Name: Manager
20. Enter Error Message: Only Managers can see that (it gets displayed if a page or application authorization fails)
21. Click “Create”

To test our authorization scheme, we have to create users and assign groups to them, then apply the authorization to some pages, regions or items. But I’m sure you already know how to do that

In APEX 4.0, you would have probably built the authorization scheme using an exists SQL query. And copied the query to every other group authorization scheme (Is Sales, Is Accounting, …), which is harder to maintain. Plugins can help to encapsulate the authorization code in one place and prevent mistakes.

Because EA1 users do not have easy access to APEX package specs, here are the data type declarations for authorization plugins:

create or replace package wwv_flow_plugin as
...
type t_authorization is record (
    id                   number,          -- internal id of authorization scheme
    name                 varchar2(255),   -- authorization scheme's name (see step 17)
    username             varchar2(255),   -- current user's name
    attribute_01         varchar2(32767), -- plugin attribute values 1 to 15
    attribute_02         varchar2(32767),
    attribute_03         varchar2(32767),
    attribute_04         varchar2(32767),
    attribute_05         varchar2(32767),
    attribute_06         varchar2(32767),
    attribute_07         varchar2(32767),
    attribute_08         varchar2(32767),
    attribute_09         varchar2(32767),
    attribute_10         varchar2(32767),
    attribute_11         varchar2(32767),
    attribute_12         varchar2(32767),
    attribute_13         varchar2(32767),
    attribute_14         varchar2(32767),
    attribute_15         varchar2(32767) );

type t_authorization_exec_result is record (
    is_authorized        boolean );        -- set to true if authorization succeeds
...
end wwv_flow_plugin;

The 2nd type might seem excessive, but we prefer records, so extensions in later releases will not change function signatures.

EDIT: 2011-08-25
There was an inconsistency in the record types t_authorization and t_authentication that we could fix before the 4.1 release. Both now contain an attribute username, I renamed t_authorization‘s user_name. Thanks go to Scott Spendolini for finding that issue.