Rob Crittenden wrote:
> Simo Sorce wrote:
>> ----- Original Message -----
>>> From: "Rob Crittenden" <rcritten(a)redhat.com>
>>> To: "Ipsilon" <ipsilon(a)lists.fedorahosted.org>
>>> Sent: Tuesday, May 5, 2015 2:13:48 PM
>>> Subject: Patches pending review
>>>
>>> Here is a list of the patches I have pending review:
>>>
>>> ticket 35:
>>>
https://fedorapeople.org/cgit/rcritten/public_git/ipsilon.git/.git/commit...
>>
>> This one looks good but seem to need a rebase, cherry-pick barfs.
>
> Rebased.
>
>>
>>> ticket 90:
>>>
https://fedorapeople.org/cgit/rcritten/public_git/ipsilon.git/.git/log/?h...
>>
>> I've had no time to look at this one yet.
>>
>>> ticket 111:
>>>
https://fedorapeople.org/cgit/rcritten/public_git/ipsilon.git/.git/commit...
>>
>> This is reaaaallly ugly, can we rather have a config option we look for and not
enable sssd
>> if this optoin is not set ?
>> This way you *can* enable/disable it via the admin UI, which is handy if you are
testing
>> stuff as an admin, you just shouldn't be able to change the configuration.
(mark the module
>> cnfiguration with a "read-only" property somewhere ?
>
> No argument there about the ugly. I was trying to avoid creating a whole
> new mechanism to manage this one plugin, and I think I was looking at
> enable/disable differently.
>
> So I was looking at a much lower level, where disabling the plugin would
> actually unconfigure it in sssd, apache, etc rather than just having the
> info plugin not fire when a user authenticates. Configure is similar. If
> the plugin was enabled at install time then one can turn it on/off but
> if not, you're stuck.
>
> The other complicating factor is that the same enable/disable code gets
> called both by the UI and during startup, so some state information is
> needed to know whether one can properly allow it or not.
>
> I can see about setting a config option during install that would
> indicate whether the underlying plumbing is configured or not and
> perhaps base enable/disable requests on that. I'll take a look.
>
>
>>> ticket 116:
>>>
https://fedorapeople.org/cgit/rcritten/public_git/ipsilon.git/.git/commit...
>>
>> I think we shouldn't really allow non-mutual auth, if that check is because
mod_auth_gssapi
>> fails to reutn the token on a 200 OK, then we just need to require a new enough
>> mod_auth_gssapi, Ifixed that bug in master a couple of weeks ago, and can make a
release
>> if necessary.
>
> Yeah, that'd be great. In the meantime I'll pull the upstream source and
> do some local testing.
I tested upstream release 1.2.0 and mod_auth_gssapi is still not sending
back a header for mutual auth when auth succeeds.
Are you sure you got 1.2.0 in the test environment ?
Simo.
--
Simo Sorce * Red Hat, Inc * New York