Hi Stefan This is not possible at the moment.You can set a policy in the scope “user” to define which type the user is allowed to enroll. But at the moment this is not reflected in the UI list.Kind regardsCornelius
Cornelius KölbelCornelius.koelbel@netknights.it+49 151 2960 1417
NetKnights GmbHhttp://netknights.itLandgraf-Karl-Str. 19, 34131 Kassel, GermanyTel: +49 561 3166797, Fax: +49 561 3166798
Amtsgericht Kassel, HRB 16405Geschäftsführer: Cornelius Kölbel-------- Ursprüngliche Nachricht --------
Von: Stefan Steuer cloud.steuer@googlemail.com
Datum: 06.03.2015 17:19 (GMT+01:00)
An: privacyidea@googlegroups.com
Betreff: Re: Debian + Error during installation
Dear Cornelius,please can you tell me in which file can I delete some entries of this list?
The user should not see all the options 
On Tuesday, March 3, 2015 at 8:33:43 AM UTC+1, Cornelius Kölbel wrote:
Hi Stefan,
1st: thanks for the patience and your support to get this going!
2nd: No, there is no selfservice...
...in fact it is the very same Web UI. ;-)
I realized, that using the same WebUI produces less code and thus
hopefully less bugs. There are still enough bugs anyway.
OK, the normal user can log in to the very same UI using his
username@realmname.
(In the system config you should set the "split @ sign config
entry)
Then the user can authenticate with his password from the userstore.
In SQL this is a bit difficult, since each SQL table could store the
password in a different way.
With OTRS it works with my installation ;-)
When the user has successfully logged in to the "selfservice" the
encrypted JWT, that he is passed by the server, contains the
ROLE=user and his username and realm. As he sends this JWT on each
request, the system can determine, that he is "only a user" and thus
provide
1. only his own tokens and
2. only audit entries, that belong to him and
3. restrict access to other resouces.
Disclaimer: User in the non-default-realm will not work correctly. I
just added the missing information in the jwt.
There are also plans for the users to be able to authenticate with
an OTP device against privacyidea
https://github.com/privacyidea/privacyidea/issues/95
thus the user would need two factors to login to "selfservice".
If by any chance you are on the Chemnitzer Linux-Tage you might come
along. There is a stand in the exhibition with privacyIDEA.
Kind regards
Cornelius
Am 03.03.2015 um 08:18 schrieb Stefan
Steuer:
It works fine! :)
My last question :D
Is there a self service for the users so that the user can
enroll his token by himself and create the QR code?
On Monday, March 2, 2015 at 10:49:24 PM UTC+1, Cornelius Kölbel wrote:
yes,
fixes this, too.
Good night.
Am 02.03.2015 um 22:32 schrieb Stefan Steuer:
> I'll try it in the Morning ;-)
> Should that File also fix the Problem while Creating a
Token for a User with "umlaut"?
>
--
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/2598a11d-e265-40c2-bad3-de19496a33d0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
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+unsubscribe@googlegroups.com.
To post to this group, send email to privacyidea@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/privacyidea/4e7df4c7-2b3c-4207-9a71-aea10b06c6e7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.