[Date Prev][Date Next] [Thread Prev][Thread Next]
[Freeipa-users] Some clarifications about IPA and SSSD
- From: Dmitri Pal <dpal redhat com>
- To: freeipa-devel <freeipa-devel redhat com>, "." <freeipa-users redhat com>, freeipa-interest redhat com
- Subject: [Freeipa-users] Some clarifications about IPA and SSSD
- Date: Wed, 17 Jun 2009 10:27:25 -0400
It seems that there is a fair bit of confusion about IPA and SSSD. It is
to some extent my fault since the freeIPA site is not frequently updated
and information is not well organized there.
The site does not reflect the state of the project so I am planning a
cleanup in August. Meanwhile I wanted to try to make things a bit clearer.
Here are some Q & A.
What is IPA 2.0 about?
Originally we planned a lot  but as it usually happens things change
and we reduced the scope a bit. It is not because we do not want to
deliver the functionality but because it is just too much to chew in one
release. Also our view of P and A parts of IPA changed a bit. For P we
were originally thinking about a broader set of the system management
capabilities. It turned out that there is a big overlap between what we
were planning to do and some very flexible configuration management
solutions that already exist. We decided not to reinvent the wheel and
try to integrate with such solutions. To do this effectively it made
sense to separate this effort form IPA v2 and do it a bit later focusing
right now on I of API and A of IPA. In IPA v2 the P will be represented
by robust centrally managed host based access control.
The A of IPA is the audit server. From the very beginning we realized
that it would make sense to build A in such a way that it can be
installed independently from I of IPA. This independence allows
different delivery schedules for audit server than for the I part of IPA
that consists of KDC, DS and management framework.
So IPA can be viewed as a group of related sub projects that might have
One of such sub projects is SSSD which stands for System Security
It is a client side framework that allows caching of the identity
information for offline use and support of multiple sources of the
identity information at the same time.
There are some misconceptions about SSSD that I will comment on below.
So here is the core list of features that IPA v2 project family will
I of IPA
* Host Identity, host enrollment, host keytab provisioning
* Integration with CA
* Issuing certs and tracking certs that need auto renewal
* More robust services management
* New management framework, more flexible and extensible
* Rich UI and CLI interfaces
* NIS and DS to IPA migration with NIS support of legacy systems
* Integration between IPA users, groups, hosts, host groups and
netgroups for NIS
* Automount as LDAP map
P of IPA
* Host based access control
A of IPA
* Collection of the log files and individual events, delivery of them to
the audit server and storage on the server for the analysis with the
third party tools. We plan to build out tools in v3.
The functionality that we want to deliver required a client component.
But instead of building a specific IPA client we split the client side
into common part that can be used with different identity solutions and
specific IPA part. This common component is SSSD. It provides a
framework for identity services. It allows multiple back ends. IPA is
just one of them. Others would include LDAP, NIS, Local files. There is
no limitation of what can be an identity provider. There are plans to
make Samba winbind be a back end in future. Any third party
authentication vendors are welcome to build their own identity provider
SSSD solves several important issues. The first one is caching identity
data for offline authentication and NSS lookups. Second is the ability
to get data from multiple identity sources at the same time. There are
other benefits that lay foundation for the future better user login
experience and support of contemporary authentication methods and multi
factor authentication policies.
Does SSSD require IPA?
No. SSSD can have other data providers. IPA is not required. We view the
SSSD is a core part of an OS. There is already interest from some
distributions to port it. We start with Fedora but it is just one of the
distros we are targeting. SSSD is written in C. It does not have a lot
of dependencies. Most of them have been already ported to different
distros so broad support of SSSD is possible and realistic.
Does IPA require SSSD?
To take advantage of the full IPA v2 functionality SSSD is required. But
it is clear that it is not possible to put SSSD everywhere. For the
systems that can only support NIS IPA server will act asd a NIS server,
for systems that can have pam_krb5 or pam_ldap and nss_ldap IPA can
still be an authentication and identity server as it was in v1.
What is relation between NSS_LDAP and SSSD?
Nss_ldap is known to have performance and scalability issues. SSSD
addresses these issues by creating a robust caching mechanism. However
SSSD can't replace NSS_LDAP everywhere right away. It is unrealistic.
This is one of the reasons why nss_ldap issues are still being
addressed. It might appear that the two hands do not know what the other
is doing. They actually do and we intentionally clean the old solution -
nss_ldap , providing nss_ldapd for better performance and scalability,
and build a new one - SSSD that will eventually replace the nss_ldap in
a long run.
Any feedback is welcome!
[Date Prev][Date Next] [Thread Prev][Thread Next]