Token enrollment wizard problem

[Sergey Kolosovski]

Hello Cornelius!

Could you please bring some light regarding token enrollment wizard?

I tried to find any info about usage of it here and on readthedocs, but it seems like it isn't documented well..

I have a user policy configured, which describes which token types are available for enrollment and which parameters(max/min pin, otplen, etc..). And when a user clicks on the Token enrollment wizard button it receives a page with only "Enroll a new token" text and "Enroll token button". But after click on it an alert appears "The minimum OTP PIN length is 4". Also in audit logs

POST /token/init

The minimum OTP PIN length is 4

Could you please give a hint of how to use it? What does it require?

[Cornelius Kölbel]

Hello Sergey,

did you know the youtube video?
You may get a better understanding here.
https://www.youtube.com/watch?v=diAGbsiG8_A

At which point do we need to improve the documentation?

The token enrollment wizard does entroll a token _without_ an OTP PIN
(it supposes, you use otppin=userstore)

This is why you get the error message.

Kind regards
Cornelius

> --
> Please read the blog post about getting help
> https://www.privacyidea.org/getting-help/.
>
> For professional services and consultancy regarding two factor
> authentication please visit
> https://netknights.it/en/leistungen/one-time-services/
>
> In an enterprise environment you should get a SERVICE LEVEL AGREEMENT
> which suites your needs for SECURITY, AVAILABILITY and LIABILITY:
> https://netknights.it/en/leistungen/service-level-agreements/
> ---
> 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.
> Visit this group at https://groups.google.com/group/privacyidea.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/privacyidea/f61f1092-329e-4203-aea4-7f8f70ec6d71%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

[Sergey Kolosovski]

Hi and thank you for the youtube demo!

Wizard is a good feature.

Now as you explained,

The token enrollment wizard does entroll a token _without_ an OTP PIN 
(it supposes, you use otppin=userstore) 

it became much clearer to understand the behavior.

But I have an idea!

Parameters  for otp pin are described in the user policy. So PI aware about what token could exist in the particular realm. Why it don't just fetch those parameters of the current user realm, for instance PI knows that user limited by a policy to have pin code of:

minimum 4 chars

maximum 10 chars

contents: "nc"

and generate a pin-code for user?

In this case it could be, for instance, "123asd321"

And then propose it to a user together with the QR?

As for documentation,

the only place I found a "wizard" keyword is 

http://privacyidea.readthedocs.org/en/latest/policies/webui.html?highlight=wizard

So maybe here you could add more detailed explanation about what does PI require for token enrollment using wizard

[Cornelius Kölbel]

Am Freitag, den 22.04.2016, 05:26 -0700 schrieb Sergey Kolosovski:
> Hi and thank you for the youtube demo!
> Wizard is a good feature.
> Now as you explained,
> The token enrollment wizard does entroll a token _without_ an
> OTP PIN
> (it supposes, you use otppin=userstore)
> it became much clearer to understand the behavior.
> But I have an idea!
> Parameters for otp pin are described in the user policy. So PI aware
> about what token could exist in the particular realm. Why it don't
> just fetch those parameters of the current user realm, for instance PI
> knows that user limited by a policy to have pin code of:
> minimum 4 chars
> maximum 10 chars
> contents: "nc"
> and generate a pin-code for user?
> In this case it could be, for instance, "123asd321"
> And then propose it to a user together with the QR?
>

This is a nice idea for generating the OTP PIN.
But how does the user login to the UI in the first place???

The enrollment wizard unleashes all its power in case the user has no
token, yet. Then the user can login with his ldap password. Enroll his
first token and then use the two factors ldap password + otp.
(This was the original scenario - but it is always cool to enhance)

>
> As for documentation,
> the only place I found a "wizard" keyword is
> http://privacyidea.readthedocs.org/en/latest/policies/webui.html?highlight=wizard
>

Ok, this needs to be improved!
https://github.com/privacyidea/privacyidea/issues/381

Thanks a lot
Cornelius

>
> So maybe here you could add more detailed explanation about what does
> PI require for token enrollment using wizard

> --
> Please read the blog post about getting help
> https://www.privacyidea.org/getting-help/.
>
> For professional services and consultancy regarding two factor
> authentication please visit
> https://netknights.it/en/leistungen/one-time-services/
>
> In an enterprise environment you should get a SERVICE LEVEL AGREEMENT
> which suites your needs for SECURITY, AVAILABILITY and LIABILITY:
> https://netknights.it/en/leistungen/service-level-agreements/
> ---
> 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.
> Visit this group at https://groups.google.com/group/privacyidea.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/privacyidea/4cbbb329-234e-43c4-b028-0c4b2a6df81b%40googlegroups.com.

[Sergey Kolosovski]

But how does the user login to the UI in the first place??? 

You mean, for the first time, when it doesn't have any token?

For example in my scenario any user from LDAP resolver can log in to WEB UI into default realm(which contains this LDAP user store) using their AD login and password. This is due to login_mode by default is "userstore" in webui policy.

Then, I suppose, PI can check policies related to token enrollment for this current realm and propose a generated QR and PIN for the user in the token enrollment wizard process.. If it's not seems to be too complicated or maybe contradicts with the idea...

The enrollment wizard unleashes all its power in case the user has no 
token, yet. Then the user can login with his ldap password. Enroll his 
first token and then use the two factors ldap password + otp.

Sorry, couldn't find how and where it is set up to use LDAP password instead of a PIN code..

I only see that User scope policy contains options to set pin characteristics - length and content. In addition every token assignment user interface has fields for pin set up(to be entered by user or admin). This would be useless fields if a pin would be equal to ldap password.

But it seems that I read about it somewhere formerly but can't find and remember :(

In any case, treat it as a IDEA(not exactly Privacy though.. ;) ) about how to make token enrollment wizard more flexible. For my opinion and in my case even standard token enrollment mechanism is maximally minimized so the only thing a user needs to enter is pin, but users just get confused sometimes when they intuitively go to the token enrollment wizard, push the button and get a red alert like "the minimum pin length is 4" :)

[Cornelius Kölbel]

Hi Sergey,

honestly the token enrollment wizard was developed together with a
customer...
...to get the most simple way for the user. This simple way excluded the
token pin.

Of course you are right. We could add more configuration policies to the
enrollment wizard to also allow
1. setting a PIN
2. or creating the random PIN

In case of "setting a PIN" I am not completely convinced. Because it
gets more complicated and the user will have to "understand" the UI. He
will have additional UI elements (PIN entry). So - he could soon use the
normal token enrollment, since it is only a bit more complex.

Hm, in case of "creating a random PIN" the user will not use this random
PIN. Because it sucks. So he will have to reset the PIN. So either we
return to 1 "setting a PIN" or we set a random PIN and than the user has
to reset this PIN. Argh. No.

I think there is a way to also use PIN + OTP with the enrollment wizard.

Just thinking this through, back and forth to get the best way of doing
it.

Kind regards
Cornelius

> --
> Please read the blog post about getting help
> https://www.privacyidea.org/getting-help/.
>
> For professional services and consultancy regarding two factor
> authentication please visit
> https://netknights.it/en/leistungen/one-time-services/
>
> In an enterprise environment you should get a SERVICE LEVEL AGREEMENT
> which suites your needs for SECURITY, AVAILABILITY and LIABILITY:
> https://netknights.it/en/leistungen/service-level-agreements/
> ---
> 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.
> Visit this group at https://groups.google.com/group/privacyidea.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/privacyidea/9cc918ba-0c82-4b7c-bef3-de25220da692%40googlegroups.com.

[Sergey Kolosovski]

Hello Cornelius!

In continuation of the wizard discussion, may I drop a feature request if you don't mind?

Considering the fact that token enrollment wizard works with userstore passwords as pin codes, but some organizations may have strict policies of pin codes - what they should consist of, and may or may not they ever be a userstore password - we can say that in some cases, as I described, for instance, TEW provides only errors and personally I don't think something is terrible here. But some users when got to the OTP system get confused maybe and choose wizard instead of enroll token(although there only needs to be a pin code entered twice and a button to be hit). And this is regardless we have well-documented instructions where to go and where to push..

So, is it good and possible improvement on your opinion to add a checkbox somewhere in user policy to enable or disable the token enrollment wizard(actually to hide the button)? For example, as the token assign button which is being controlled by "assign" policy in user policy set.