PirvacyIDEA and Shibboleth Identity Provider 3: No token validation

Dear Community,

We at the RWTH Aachen University are trying to setup PrivacyIDEA as MFA solution. The Setup of the software was easy, but now we have a problem with the integration in Shibboleth Identity Provider 3. We are using this “plugin” for shibboleth https://github.com/wraezor/privacyIDEA-shibboleth-tfa and in the setup it is asking for


I tried hier a lot of different users (local /etc/passwd realm with user, a user in our realm…) but everytime i try to authenticate, i get this error:

[2019-04-30 10:33:41,284][27515][140129695938304][INFO][privacyidea.lib.user:357] User u’“shib@local”’ from realm u’rwth-aachen. de’ tries to authenticate
[2019-04-30 10:33:41,287][27515][140129695938304][ERROR][privacyidea.lib.user:371] The user User(login=u’“shib@local”’, realm=u’rwth-aachen. de’, resolver=’’) exists in NO resolver.
[2019-04-30 10:34:05,697][27515][140129763079936][INFO][privacyidea.lib.user:357] User u’“shib@local”’ from realm u’rwth-aachen.de’ tries to authenticate
[2019-04-30 10:34:05,699][27515][140129763079936][ERROR][privacyidea.lib.user:371] The user User(login=u’“shib@local”’, realm=u’rwth-aachen. de’, resolver=’’) exists in NO resolver.

My config:

Realm: rwth-aachen. de
Resolver: LDAP-Resolver
Realm: local
Resolver: /etc/passwd

Any ideas how i can resolve this?

Hello and welcome to privacyIDEA.

I do not know the shibboleth plugin. But the naming pi.Serviceuser sounds like and administrative service account.
You can setup such an account as internal admin using pi-manage.
You might want to read a bit about administrators:

Hi cornelinux,

thx for the help :slight_smile: i can now verify the tokens

for the plugin, the following steps are required:

  • Generate API Key: pi-manage api createtoken -r admin
  • Add the corrosponding admin account: pi-manage admin add

And sorry for the delay, i was very busy…

I do not know how the plugin is written, if it requires an API-token or a service account.

We always write our plugins this way, that we configure a service account with password. This service account then first runs an

POST /auth

to acutally receive an API-token. And then this is used to run the triggerchallenge.
(Maybe too much of an internal view)