[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