Support » Plugin: Shibboleth » Clarification of Default Role: None, accounts still created with no role mapping

  • Resolved jakramer


    According to the help text in the Authorization configuration section,

    “If a user does not map into any of the roles above, they will be placed into the default role. If there is no default role, the user will not be able to log in with Shibboleth.”

    However, with no role mappings specified and Default Role set to (none), accounts are still created and users can still log in (albeit with no additional access).

    I’m not sure if I’m misunderstanding the intent or if I have something misconfigured.

    The desired behavior is to not create accounts for users with no role mapping. Is it possible to do that?

    I read through previous discussion of this issue here
    and here:

    but I’m still not clear whether this is possible at this time.

    Thanks and apologies if I’m just not getting it.

Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Contributor Jonathan Champ


    I think I see what you’re talking about. The situation is that when “Automatically Create Accounts” is enabled and default role is “None” it still creates accounts with no role. The documentation definitely needs an update, but I’m not sure if there is only one valid use case.


    1. Modify shibboleth_create_new_user() so that when the result of shibboleth_get_user_role() is blank, it exits the function before creating a user
    2. Modify shibboleth_create_new_user() so that when the result of shibboleth_get_user_role() is blank, the user create is dependent upon a new setting, such as shibboleth_allow_user_create_without_role
    3. Do nothing and document that when “Automatically Create Accounts” is enabled, that it will create users even if there is no mapped role

    I like the idea of #1, but it would break situations where people currently require users to log in, but don’t assign a default role. At the same time, perhaps if we warn people that they should probably just assign the default role of Subscriber (or a custom role with no capabilities) if they want to allow user creates, we’d be fine. #2 seems like a way to make everyone happy, but it’s yet another configuration option. The documentation part of #3 should definitely happen, but should align with the decision made. Otherwise, I’m leaning away from #3 right now, because the purpose of the change that put us in this situation (using existing user roles) is unaffected by this specific change (which only affects user creates).

    Plugin Contributor Jonathan Champ


    Looks like there’s already a similar request:

    If you’re on board, we should continue the discussion there.

    Sounds good. Thank you.

Viewing 3 replies - 1 through 3 (of 3 total)
  • You must be logged in to reply to this topic.