Ipsilon 1.0 Transaction issues.

John Dennis jdennis at redhat.com
Wed Oct 7 18:01:52 UTC 2015


On 10/07/2015 06:59 AM, Jamie Lennox wrote:
> 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.

The urn in pysaml2 is incorrect, lasso is using the correct value. 
Values that are supported in both SAMLv1 and SAMLv2 retain their 
original definition from SAMLv1.

This is the SAMLv2 spec:
https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf

Refer to Section 8.3 (line 3275).

Note Sections:

   8.3.1 (Unspecified)
   8.3.2 (Email Address)
   8.3.3 (X509. Subject Name)
   8.3.4 (Windows Domain Qualified Name)

*all* retain their SAML:1.1 namespace. Only when you get the newly added 
in SAMLv2:

   8.3.5 (Kerberos Principal Name)
   8.3.6 (Entity Identifier)
   8.3.7 (Persistent Identifier)
   8.3.8 (Transient Identifier)

is the SAML namespace bumped to SAML:2.0

> 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.

I'm currently reviewing your proposed patch and making sure I understand 
the existing and future code issues and will follow-up shortly.

Something must have changed with how the user attributes are fetched 
from the info plugins because I know I tested this and it worked, but 
that was going back to around March of this year.

> 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.


-- 
John


More information about the ipsilon mailing list