Authenticate as user/instance

[Tiago Elvas]

The domain will be made of several machines, which will be running
dedicated applications.

These applications will be operated by persons. So, for several of these
apps, we'll have profiles such as admin or user. So, in LDAP we'd have
different profiles for the admin user for each application. The same
"Operator" can have admin profile on one app and user profile on another
one. That's why the need of identify principals like this, I guess...

As an example:
Having:
- applications: Application1, Application2
- hostname: Machine1, Machine2
- users: Operator1, Operator2
- app profiles: admin, user

i.e: if *Operator1* logs into *Machine1*, he'd have access to app profile *
admin* on *Application1*
i.e: if *Operator2* logs into *Machine2*, he'd have access to app profile *
admin* on *Application2**
*
The app profiles are configured in LDAP DB.

I'll need to unserstand what "username mapping functionality of MIT krb5"
is...

thanks for your answer Nico!

On Tue, Mar 13, 2012 at 7:45 PM, Nico Williams <nico at cryptonector.com>wrote:

> On Tue, Mar 13, 2012 at 4:50 AM, Tiago Elvas <tiagoelvas at gmail.com> wrote:
> > Thanks for your reply.
> > The idea is to have a domain of several machines where each one has its
> own
> > dedicated purpose and not having a requirement to have unique user ids
> for
> > the whole system.
>
> There was a long thread on heimdal-discuss a while about about similar
> concepts.  There the user wanted to be able to manage remote
> filesystem access controls for similar "accounts"on many clients but
> as different entities.
>
> I'm not at all sure what it is that you want to do.  Perhaps you want
> all these principal names for authorization purposes.  But perhaps you
> want them for simplifying key management.  Or perhaps you just want
> better auditing on the theory that the principal name tells you the
> client hostname, assuming the principal's credentials are not being
> used on the wrong host.
>
> Are these operators humans interacting with computers?  Or automated
> services?
>
> > So that if the operator logs in in machine1(being machine1 a fqdn) he has
> > the authentication as principal "operator/machine1" and then in ldap he
> has
> > his own profile. If he logs in in machine2 he'll get a different ldap
> > profile.
>
> "then in ldap he has his own profile".  Do you mean own user account?
> If so it sounds like you want to use this idea for authorization
> purposes.  If so, and if you're intending to use normal Unix/LDAP user
> accounts for authorization, then you'll probably need to read up on
> the principal to username mapping functionality of MIT krb5.
>
> > Probably as John Devitofranceschi, I could generate keytabs for each user
> > and force the authentication with that key. But I do not want to perform
> a
> > kinit each time I login. Unless I modify the .bashrc file to do that...
>
> You can almost certainly coax Russ' pam-krb5 to do what you want,
> either via existing features or if need be by hacking on it.
>
> Nico
> --
>