OTP pin authentication based on token type

[Stephen Hobbs]

Is it possible to set the OTP pin to tokenpin or userstore based on the token type? i.e for email email tokens use the tokenpin, and for HOTP use the userstore? I tried to setup two authentication policies but get a "There are contradicting policies for the action otppin!" error

Stephen

[Cornelius Kölbel]

Hi Stephan,

first this would require a policy to contain a tokentype - which it does
not.
2nd: You only know the tokentype, if you know the token. And the token
is sometimes determined by the otp pin.

Imagine a login screen.
The user enters "something".
There is no easy, straigtforward way for privacyIDEA to know if this is
supposed to be OTP PIN, an LDAP password or a PIN+OTP...
It only knows the user, who can have several tokens.
(At least I do not know an easy way - would be happy to implement such
one)

Anyway: You have the following possibilities at the moment:

You can decide based on

1. Client IP address
2. User Resolver.

1.
So lets say, you know that logging in from the Application A will always
happen with email-tokens, than you can create a policy with the Client
IP if application A, that says: OTP PIN required.

If the login is from somewhere else, you can say: LDAP password
required.

2.
If _you_ know which users will only have an EMAIL token, you can put
these users in their own resolver "email-users". Lets say by a group
membership.
All other users can be located in resolver "hardware-users".

Now you can join both resolvers in your default realm.

Create a policy with
resolver=email-users
otppin=privacyidea

and a second policy
resolver=hardware-users
otppin=userstore


I am happy to discuss this.
And hopefully we come up with a really good idea, that can make a shiny
new cool feature in the next PI release.

Kind regards
Cornelius

> --
> You received this message because you are subscribed to the Google
> Groups "privacyidea" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to privacyidea...@googlegroups.com.
> To post to this group, send email to priva...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/privacyidea/d222ed4c-357b-4873-9cfb-a571be14f7db%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

--
Cornelius Kölbel
corneliu...@netknights.it
+49 151 2960 1417

NetKnights GmbH
http://www.netknights.it
Landgraf-Karl-Str. 19, 34131 Kassel, Germany
Tel: +49 561 3166797, Fax: +49 561 3166798

Amtsgericht Kassel, HRB 16405
Geschäftsführer: Cornelius Kölbel

[Stephen Hobbs]

Cornelius

Thank you for the detailed response.

As a feature request would it be possible to add an one time use "Emergency token(s)" type which could be used when the user does not have access to their usual OTP method. Similar to the registration token, but managed by user and policy based configurable length and complexity.

thanks

Stephen

[Cornelius Kölbel]

Hello Stephen,

first I am sorry for misspelling your name in the previous mails.

There are different technical possibilities to do this. But to find the
best technical solution I would like to first understand your
non-technical needs.

Can you tell me what you want to achieve on a top level view?

Thanks a lot
Cornelius

> https://groups.google.com/d/msgid/privacyidea/3cd33da3-a513-41da-9df9-a3763b41c470%40googlegroups.com.

[Stephen Hobbs]

Cornelius
We currently use google auth, pam module which during setup provides the user with 5 emergency scratch codes. These are a useful backup when does not have access to their cell phone. 

Stephen

[Cornelius Kölbel]

Hi Stephen,

the nearest thing that comes to the scratch codes are the registration
tokens. These tokens can be used once and are deleted after usage.

So you could enroll 5 registration tokens to the user via a script and
print the codes on a sheet of paper for the user.

The question is, if you want to accept that the user does not bring his
normal token or if you want to "educate" them

There is also the "lost token process", where you can create a temporary
random password.

In addition you can add

* validity period and
* maximum token usage to each token.

I.e. you can create tokens, that are allowed to be used only once.

Kind regards
Cornelius

> https://groups.google.com/d/msgid/privacyidea/fd0e7a5d-ea2d-4e47-ab9f-53964a5ff69e%40googlegroups.com.

[Jochen Hein]

Stephen Hobbs <hobb...@gmail.com> writes:

> As a feature request would it be possible to add an one time use "Emergency
> token(s)" type which could be used when the user does not have access to
> their usual OTP method. Similar to the registration token, but managed by
> user and policy based configurable length and complexity.

At work we use smartcards to authenticate to our VPN (with some other
software than privacyidea). As it happens, smartcards take some time to
produce and sometimes they break. If that happens our users get a
"softtoken", which is a client certificate with limited lifetime (some
months) to get access to our VPN. Normal authenticatin is with
smartcard and PIN, softtoken authenticates against our directory service.
Just to decribe a useful usecase...

Jochen

--
The only problem with troubleshooting is that the trouble shoots back.