Force specific Token / Pass if specific Token type is not assigned

H3GE · May 28, 2020, 7:28pm

How does the tokentype authorization policy work?

I have just connected my NPS (for my Remote Desktop Gateway) to privacyIDEA via FreeRadius and I’m now able to login using the PUSH token, if I have one set up. I also have made a authorization policy (with a realm filter only) where the push tokentype is forced.

But as long as my user has only one hotp token assigned, /validate/check runs against the hotp token, which cannot succeed, because in the pass argument there is no info at all (truncated by NPS), so the hotp error counter goes up.

I would like to use this in combination with passOnNoToken so that other users without a push token, but with other type of token assigned, are able to login. (which seems to be impossible without transfering the tokentype check from authorization to authentication)

I also tried it with Weblogin (via ADFS) and have one totp and one hotp token assigned, but I’m able to login with both token types, so the authorization policy seems to have no effect at all.

!!!Log Entry Secured by SecureFormatter!!! [2020-05-28 18:54:14,942][177525][140512237389568][DEBUG][privacyidea.lib.policy:527] Policies after matching active: [{‘name’: ‘DUMMY-FORCE_Tokentype’, ‘active’: True, ‘scope’: ‘authorization’, ‘realm’: [‘mydomain.at’], ‘adminrealm’: , ‘adminuser’: , ‘resolver’: , ‘check_all_resolvers’: False, ‘user’: , ‘client’: , ‘time’: ‘’, ‘conditions’: , ‘priority’: 1, ‘action’: {‘tokentype’: ‘totp’}},…]

Kind regards.

cornelinux · May 29, 2020, 6:27am

Hello Hege,

welcome to the privacyIDEA community.

I think you are mixing up a lot of topics and information. I can not get my head around this in 2 minutes. Maybe you need to untangle this.

Kind regards
Cornelius

H3GE · May 29, 2020, 1:58pm

Hello Cornelius,

thanks for the fast answer.

I think I just found a open feature request that would completely solve (and answer) my primary issue.

But to untangle it a bit - I’m currently struggling with the tokentype - authorization policy, no matter what I have configured, I’m always able to login with all of my three token types (push,totp,hotp).

ADFS Login with HOTP -> Plugin calls
POST /validate/check
but the variable tokentype seems to be null in line #209 in file api/lib/postpolicy.py

DEBUGINFO tokentype:None and allowed tokens is {‘totp’: [‘DUMMY-FORCE_Tokentype’]}

I have to keep looking, do you have any idea why the tokentype is null?

Regards,
Hege

cornelinux · May 30, 2020, 8:21pm

The variable you mention in line 209

github.com

privacyidea/privacyidea/blob/master/privacyidea/api/lib/postpolicy.py#L209


This policy function is to be used in a decorator of an API function.
It checks, if the token, that was used in the API call is of a type that
is allowed to be used.


If not, a PolicyException is raised.


:param response: The response of the decorated function
:type response: Response object
:return: A new (maybe modified) response
"""
tokentype = response.json.get("detail", {}).get("type")
user_object = request.User
allowed_tokentypes = Match.user(g, scope=SCOPE.AUTHZ, action=ACTION.TOKENTYPE,
                                user_object=user_object).action_values(unique=False)
if tokentype and allowed_tokentypes and tokentype not in allowed_tokentypes:
    # If we have tokentype policies, but
    # the tokentype is not allowed, we raise an exception
    g.audit_object.log({"success": False,
                        'action_detail': "Tokentype {0!r} not allowed for "
                                         "authentication".format(tokentype)})
    raise PolicyError("Tokentype not allowed for authentication!")

is read from the HTTP response. So after the authentication was successful.
If the authentication is not successful, the variable is not set.

If you are in the first step of a challenge response authentication (with more than one token), the variable is also not set, because there is not one distinct token.