Initial OTP token configuration

[Kurt Bendl]

Hi,

I'm planning how we will set up an account's initial OTP exchange.

I'm hoping there's a "best practices" method to provision a new account.

Here's what I'm thinking. 

(please, tell me a better/easier way if you have a "best practices" workflow.)

* User creates an account request, which includes an acceptable password.

* We put that account request into a "stage" OU.

* A human approves/denies the account request.

* If approved, the user can then change the account password.

* Beyond setting the initial password, the user must set up OTP before gaining any more access.

* We ask the user to go get an OTP app (like FreeOTP), which they joyfully do.

* We SMS a one-time/time-limited URL to the user's cell phone. 

  (Might we leverage the autoassignment enrollment policies for this? Something else?)

* User goes to the URL, which is the OTP sign-up/config page.

* Once the OTP is configured, we move the user to a realm that requires OTP from that moment on.

Maybe I'm missing some functionality or feature in PrivacyIDEA for doing this (I'm still reading the docs.) If so, please let me know. Any ideas or direction will be greatly appreciated.

Thanks!

  -kb

[Cornelius Kölbel]

Hello Kurt,

the concept how to enroll or distribute authentication devices to the
users is often a central part of an overall concept of two factor
authentication project. Depending on the size and side effects of such
an enrollment/infrastructure this can take several days doing workshops,
discussions and writing concept to the satisfaction of all people
involved.

privacyIDEA does not have THE way to distribute tokens to the users.
But it has several possibilities, so that you can look at your workflow
and processes and design the enrollment process nearly seamless into
your existing workflows.

So how do your users usually interact with IT?
Are all the users on site or are they scattered in the world?
Which identity attributes of the users are already known?

When assigning a token to the user, you need to identify the user
somehow. The quality of the two factor afterwards will be as good as the
identification process.

If you are using 2FA for remote access it might be enough, that the user
authenticates with his domain password to the web ui internally and
enroll his own token.

In other cases it might be necessary to identify the user personally,
i.e. the user needs to come to a registration desk in person.

As an example privcayIDEA comes with a registration token type.

http://privacyidea.readthedocs.org/en/latest/configuration/tokens/registration.html
http://privacyidea.readthedocs.org/en/latest/modules/lib/tokentypes/registration.html?highlight=registration%20token

You could restrict that the user may only possess one token.
Enroll a registration token to the user (automatically) and send the
registration code to the user in a trusted way (more likely snail mail
than email).

I do not get your idea with the stage OU. I assume the users already
exist, but they have no token assigned.
So I think there is no need to move the users around in the user
directory.

...more below...

Am Montag, den 20.07.2015, 15:51 -0700 schrieb Kurt Bendl:
> Hi,
>
>
> I'm planning how we will set up an account's initial OTP exchange.
> I'm hoping there's a "best practices" method to provision a new
> account.
>
>
> Here's what I'm thinking.
>
> (please, tell me a better/easier way if you have a "best practices"
> workflow.)
>
>
> * User creates an account request, which includes an acceptable
> password.
> * We put that account request into a "stage" OU.

I am puzzled, are there no user accounts, yet?

> * A human approves/denies the account request.
> * If approved, the user can then change the account password.
> * Beyond setting the initial password, the user must set up OTP before
> gaining any more access.
> * We ask the user to go get an OTP app (like FreeOTP), which they
> joyfully do.
> * We SMS a one-time/time-limited URL to the user's cell phone.
> (Might we leverage the autoassignment enrollment policies for this?
> Something else?)

The autoassignment policy is used for already existing tokens a.k.a.
hardware tokens.
http://privacyidea.readthedocs.org/en/latest/policies/enrollment.html?highlight=autoassign#autoassignment
I.e. there already must exist a token, that will be assigned just by
using it.

But you could send the registration code via SMS to the user.

> * User goes to the URL, which is the OTP sign-up/config page.

The user would go the the WebUI and login with his password and the
registration code.

As soon as he logged in, the registration token is deleted. Within the
WebUI, he needs to enroll a new FreeOTP token.

> * Once the OTP is configured, we move the user to a realm that
> requires OTP from that moment on.
>
>
> Maybe I'm missing some functionality or feature in PrivacyIDEA for
> doing this (I'm still reading the docs.) If so, please let me know.
> Any ideas or direction will be greatly appreciated.
>

Depending on how many users you want to enroll, you can also automate
the process using the REST API. This would speed up and smooth things a
lot.

As mentioned in the beginning, this things are usually discussed the
best in a personal conversation but let's try it this way here.

Kind regards
Cornelius
>
>
> Thanks!
>
>
> -kb
>
>
>
>
> --
> 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/c8851f01-b43a-495d-8409-6a1dd4aa2266%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

[Tom Cole]

We also looked at those questions and came to the easiest solution (for IT and users).

We have a web GUI that the users log into.  The GUI uses LDAP authentication.  This verifies the user.  They can then enroll a token (but only 1).  The other options they have are delete, re-sync and test.  Unless you absolutely have to I would stay away from using an OTP Pin (seemed to confuse our users - not sure why as they are all supposedly college grads).  The user than uses the token for 2FA with Palo Alto Global Protect.  They have to login to the portal with LDAP and then use the token for the gateway.  If the 2 users don't match it wont work.

[Cornelius Kölbel]

Hi Tom,

thanks for the description.

I just want to add, that you can have the same functionalities with the
privacyIDEA webui:

* user logs in with LDAP password (by defining a webui-policy)
* user can only enroll a limited number of tokens (by defining an
enrollment-policy)
* user can only delete/resync... (by defining a user-policy)

But if you prefer your own look and feel or UI, of course you can use
the REST API to add this all into a portal or webinterface a user feels
more familiar with.

This is the idea behind privacyIDEA, to give you maximum flexibility.

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/37a9fbb3-4cf9-47c0-a1d7-246a2db791d0%40googlegroups.com.

[Tom Cole]

Sorry - I realize now that I gave the impression we use our own GUI. We dont - why recreate the wheel.  We use the privacyIDEA GUI - works great.

Cornelius Kölbel

July 21, 2015 at 16:09

[Cornelius Kölbel]

No need to be sorry.

I added a video https://www.youtube.com/watch?v=pukEqI6dScQ on how to
setup tokenenrollment with the registration token, where the user will
get a registration code, that can be used once to login and enroll.

The interesting thing here is, that the user also needs two "factors"
* his userstore password (a.k.a. LDAP password)
* the registration code
when initially logging in to the portal. The registration code could be
send via a letter, thus only granting initial access to the user, if he
knows his password and if he has access to his real life mail box.
Thus the hurdle to enroll the OTP token and the necessary "identity
check" is higher than only relying on the LDAP pw.

...it was a bit late... ;-)

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/55AEE238.3000708%
> 40gmail.com.

[Kurt Bendl]

That gives me an idea. What about this:

If we get a user's phone#, verify that user's phone, 

could send that code to the user's phone (SMS)?

-kb

On Wednesday, July 22, 2015 at 1:52:53 AM UTC-6, Cornelinux K wrote:

<snip>The registration code could be

[Cornelius Kölbel]

Hi Kurt,

you could run a script like this:

1. get the tokens for the user:

http://privacyidea.readthedocs.org/en/latest/modules/api/token.html#get--token-

and check if the user already has a token.

2. If the user has not token, create registration token:

http://privacyidea.readthedocs.org/en/latest/modules/api/token.html#post--token-init

The JSON returns the registration code like this:
http://privacyidea.readthedocs.org/en/latest/modules/lib/tokentypes/registration.html#code-registration-token

3. Now you need to fetch the mobile number of the user

http://privacyidea.readthedocs.org/en/latest/modules/api/user.html#get--user-

and send the Registration Code to the user.

The user now has the registration code an can use it once to login and
enroll the OTP token.

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/e6860ea8-a7ea-46ad-b1e0-bf30df5663b1%40googlegroups.com.