User-token reference and resolver/realm

Question
1

Hi Cornelius,

I have some question regarding the relationship between user token and
resolver/realm.

I notice the following behavior. Provided the following setup:

  • a realm ‘example_realm’, using resolver ‘example_resolver’
  • a user in ‘example_realm’, identified by objectGUID ‘123-123-123-123’,
    enrolled a token serial ‘777’.

Case 1: If the ‘example_realm’ (only) is deleted, and re-added with the
exactly same name, and binded to the exactly same resolver
(‘example_resolver’), then the existing token ‘777’ of user id
’123-123-123-123’ still appears without a user name and realm.
However,
Case 2: If the resolver ‘example_resolver’ (only) is deleted, and re-added
with the exactly same name and config, and assigned back to the exactly
same realm (‘example_realm’), then the existing token ‘777’ of user id
’123-123-123-123’ is able to recover its original user name and realm info.

Is these behavior expected? or should case 1 should expect similar result
of case 2 (aka, if realm is removed and re-added with the origin identity,
the existing token should be able to recover its original user name and
realm info).

Thank you and best regards,

2

Hello Quynh,

This is the idea with the realms:

A realm is ment to be an organizational unit (grr. name clash).
So if you are running a big company realmA could be countryA and realmB
could be countryB. Each country working mostly on its own.

Tokens can be assigned to realms. So that one organizational unit owns
its own tokens, which can not be used by another country.
So even if a token is not assigned to a user, the administrator of
realmA still owns such a token, so that the token can not be used by
the admin of realmB.
This is important with hardware tokens.
Imagine each administrator would get 100 tokens. THere would be 100
tokens in realmA and 100 in realmB. Thus the admin of realmA should
only be allowed to use up 100 tokens and not those of realmB.

Now. What happens if you delete a resolver?
A realm may contain more than one resolver. So if you delete a resolver
in realmA, realmA with the remaining resolvers still exists. And thus
the token binding to realmA also still exists. Since the admin of
realmA, sill “owns” the token.

But if you delete realmA then the tokens are freed. The token binding
to realmA is released/deleted.
In fact there is a table tokenRealm
https://github.com/privacyidea/privacyidea/blob/master/privacyidea/mode
ls.py#L957
If the realm is deleted all assignments in this table are deleted, too.

As a result or side effect, the token looses its
assignment irreversibly.
And when adding the configuration again (Case 1), the token assignment
(which was lost) is not created automatically. In fact we would have to
iterate over ALL tokens, and still do not know, if the token is inside
this new realm, since the resolver could be in two different realms.

I hope this makes sense to you.

Kind regards
CorneliusAm Freitag, den 02.09.2016, 17:14 -0700 schrieb Quynh .Nhat:

Hi Cornelius,

I have some question regarding the relationship between user token
and resolver/realm.

I notice the following behavior. Provided the following setup:

  • a realm ‘example_realm’, using resolver ‘example_resolver’
  • a user in ‘example_realm’, identified by objectGUID ‘123-123-123-
    123’, enrolled a token serial ‘777’.

Case 1: If the ‘example_realm’ (only) is deleted, and re-added with
the exactly same name, and binded to the exactly same resolver
(‘example_resolver’), then the existing token ‘777’ of user id ‘123-
123-123-123’ still appears without a user name and realm.
However,
Case 2: If the resolver ‘example_resolver’ (only) is deleted, and re-
added with the exactly same name and config, and assigned back to the
exactly same realm (‘example_realm’), then the existing token ‘777’
of user id ‘123-123-123-123’ is able to recover its original user
name and realm info.

Is these behavior expected? or should case 1 should expect similar
result of case 2 (aka, if realm is removed and re-added with the
origin identity, the existing token should be able to recover its
original user name and realm info).

Thank you and best regards,

Please read the blog post about getting help
Getting help – privacyID3A.

For professional services and consultancy regarding two factor
authentication please visit
One Time Services - NetKnights - IT-Sicherheit - Zwei-Faktor-Authentisierung - Verschlüsselung

In an enterprise environment you should get a SERVICE LEVEL AGREEMENT
which suites your needs for SECURITY, AVAILABILITY and LIABILITY:
privacyIDEA Support Level

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.
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/5bc128bd-1705-4e91-8264-
c80d9acd38ec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
Cornelius Kölbel
@cornelinux
+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

signature.asc (819 Bytes)