Ipsilon 1.0 Transaction issues.

Jamie Lennox jamielennox at redhat.com
Wed Oct 7 10:59:58 UTC 2015


Ok futher ECP bugs in Ipsilon 1.0.

The value of lasso.SAML2_NAME_IDENTIFIER_FORMAT_UNSPECIFIED is
'urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified' and this is
what ipsilon is using to check for in the nameid lookup. I am
generating my metadata with pysaml2 as i need to be a bit more
advanced than what ipsilon-client-install can do and the value of
saml2.saml.NAME_FORMAT_UNSPECIFIED is
'urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified'. If i use
this value i get a NameId lookup error (even though it returns a 200 -
not sure what the spec is on this). As mostly a guess this looks like
a mistake in lasso that ipsilon can probably work around for now.

There is no code for ipsilon to consult the info plugins in the ECP
handler at the moment this work is done as part of the Login handlers
which ECP doesn't use. I'm attaching a patch that works for me but i'm
not really sure of the larger repercussions. If useful feel free to
propose or tweak or whatever.

This feels like a bit of a bad abstraction problem - but i've only
been looking at the code today and it's late. I think we're missing
something that would handle actual authentication separate from the
login forms and the providers. I'll call this authmethod just to have
a word. Authmethods are a refinement of provider like how ECP and
websso are methods of saml2 and things like user/pass or cert based
openid login would be refinements of that. This would allow us to
install the mod_authz_pam handler for ECP (which doesn't happen now)
with like an --ecp flag. At the moment there is no way to say only
handle websso or ECP from the server you just kind of get both.

Jamie


On 2 October 2015 at 06:41, John Dennis <jdennis at redhat.com> wrote:
> On 10/01/2015 02:27 AM, Jamie Lennox wrote:
>>
>> Starting a new thread as there was nowhere that really made sense to
>> inject into the old one.
>>
>> I rolled back ipsilon to 1.0 and have done some hacks to get it
>> running again. I haven't pushed changes yet but they will be there by
>> the time everyone gets up tomorrow.
>>
>> John, I'm hitting the transaction ID issue from 1.1 in 1.0 now.
>
>
> [ backtrace snipped for brevity]
>
>> I'll have a quick look into the issue but i expect it's easier for you
>> to handle it as you have already found the problem.
>
>
> I can't explain why this problem reared it's head or exactly what changed in
> what version. However, the most expedient solution is to remove the code
> that is causing the exception to be raised. This is safe because the
> exception is being raised when trying to save a value for later use, but no
> one uses that value, it was put there for bullet-proofing rather than
> necessity. In hindsight saving the SAML binding in the transaction was
> probably ill-conceived because a binding is specific to the current stage in
> a transaction series, as such it should be saved in a transaction.
>
> Attached is proposed patch, it's just deleting a block of code.
>
> Please try it and let me know if it solves the problem, or give me access to
> your VM's and I'll try it myself.
>
>> I haven't filed a bug anywhere, i wasn't sure if you'd done that already.
>
>
> I have opened ipsilon ticket #177
> (https://fedorahosted.org/ipsilon/ticket/177)
>
> --
> John
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Use-get_valid_transaction-in-saml2-provider.patch
Type: text/x-patch
Size: 1441 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/ipsilon/attachments/20151007/83b55211/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Get-groups-information-for-ECP-auth.patch
Type: text/x-patch
Size: 1882 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/ipsilon/attachments/20151007/83b55211/attachment-0001.bin>


More information about the ipsilon mailing list