[SSSD] RADIUS provider

Ondra Hujňák xhujna00 at stud.fit.vutbr.cz
Wed May 1 23:21:14 UTC 2013


I'm really sorry, I have forgotten to write you before.

I got you last time and I will try to add functionality for the second use case
later. Right now I'm doing my best to make at least first use case work ;)

The thing is, that this work is part of my bachelor thesis and only
first case is described in the specification of my work. Because my deadline
is 5/15 and as you could see my thesis is highly unfinished I will
cover only first use case in my thesis and I will try to add functionality
for second one later in my free time.

Thank you for attached diagrams,
Ondřej Hujňák

1. 5. 2013 v 17:55, Dmitri Pal <dpal at redhat.com>:

> On 04/30/2013 06:42 PM, Ondra Hujňák wrote:
>> I have pretty good howto in text of my thesis, I have attached it, but
>> apart from information about how to set up the environment it's highly 
>> unfinished and experimental text ;)
> I want to draw the attention that the introduction gives a hint on what
> you are trying to do but does not cover all the use cases.
> 
> There are two reasons why people might want to use RADIUS as a part of SSSD.
> 1) One is to use 2FA. People might have a deployment that supports OTP
> tokens. Instead of deploying special agent to the client systems that
> would be able to configure SSSD with RADIUS. In this use case the
> architecture looks like on the attached diagram. In this case all the
> components of the solution are behind the firewall.
> 2) An appliance or special device. This special device has some local
> accounts pre configured on the box in the passwd file or in SSSD. The
> authentication should happen against the  account directory but has to
> be done using RADIUS because exposing LDAP outside the firewall is a
> security risk. In this case the authentication would happen via RADIUS
> but then all the users should be mapped to a specific local account. In
> general would be nice to allow some pattern matching.  Something like:
> for each defined pattern:
> If authenticated user account matches the pattern use the local account
> associated with the pattern
> end
> 
> In config file it can be represented by something like (I am not sure
> this is the best approach, you need to think of a better one may be):
> 
> radius_remapping = admin=root, *=guest
> 
> This would mean that if the authenticated user's name is admin he should
> be remapped to the local user 'root' and his session should be as 'root'.
> For all other the session should be as 'guest'.
> This is just an example. I suspect that in reality 'root" would not be
> used but there will be a special account created as I mentioned above.
> 
> The second use case is actually more important than the first one but I
> do not see anything about use cases in your writeup yet and I suspect
> that you were focusing on the use case 1). This is fine but use case 2)
> is really what we are looking for.
> 
> 
> Let me know if you have any questions.
> 
> 
> -- 
> Thank you,
> Dmitri Pal
> 
> Sr. Engineering Manager for IdM portfolio
> Red Hat Inc.
> 
> 
> -------------------------------
> Looking to carve out IT costs?
> www.redhat.com/carveoutcosts/
> 
> 
> 
> <RADIUS.odg><RADIUS2.odg>_______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel




More information about the sssd-devel mailing list