Ipsilon 0.4.0 released
by Patrick Uiterwijk
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi all,
Just now, Ipsilon 0.4.0 has been released.
The major new features for this release are:
- - Single Logout for SAML2 (SP-initiated)
- - SAML IdP metadata now expiring and automatically regenerated
- - New policy framework for mapping and filtering attributes
- - Improved request/response logging
- - Uninstallation support added to the installer
For more information, please see the release[1] page for version 0.4.0.
Thanks to everyone who helped in this release, and let's keep moving forward towards version 1.0!
Patrick
[1]: https://fedorahosted.org/ipsilon/wiki/Releases/v0.4.0
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBCgAGBQJU8IHJAAoJEIZXmA2atR5Qa4MQAKHrtQWKqKmk2897DE/XnPka
8I+mgTqhW+Lhp6Nmztis0FVY43c7R9eOt2p5ELpX0S+MOO+VD8EfySywthXdrjnE
AoOeVVybdhdq+AuUdvgVNG8bsYHUoGFP0PwOBP49NqMIHKC3VYWZur8o3qg/2Vsp
Iavdn/oiwuyOrS5by12ca0m4Sj5CjLbOSghs8T9D8PMd5biX9AZmQfSqhNtpQcbk
faqkqhcO/B3i/Tt9n3oMOLNstM6oZEcdhCbvSf7JoZlbBC8FYqRietwXeOmAM3TS
2adfDgGSjTp0QqtPtmlM/wRTtSwWAPmthxfZZXXeRBxAkIEydMdgxVv6LLIiqqY/
NKX8lGCMsNBCzpA8Lrts3EQ8NyXCS/x6wCcP6Q8QuYTgqtlV02sN0YrVASjgfuC4
IkzC8yewmOC5aZmW7BUWfqtuY+ztz+DAPCl0QvV3HINVdELITj9jwdyMYF9FrDRu
fkqbPH4panxIdE1kj9Ni4fC8FdHTfRshsH/AutrDxU2g0Gz2wbrBZopLYyn/9sJR
0kHTQJoOEDKnFVv2ToJykweOsoxW3E8HVuIWV/jSAzBoOuesVvpQ0TMkUBy/FeVN
0/7nWeMtwLH1SMKOu1R7oXbmzeqKSRaFCsRghmnu0uR8rJuQwbnFRmTQR4cjML8p
7nNIRVLEmGiYOoGAaTSG
=A55L
-----END PGP SIGNATURE-----
9 years, 2 months
Transaction questions
by John Dennis
I have a few questions about how Transactions are used in Ipsilon.
Each of the AuthenticateRequest classes (openid, persona, saml2)
create a Transaction object in their _preop handler. But
KrbAuth.root(), KrbError.root(), LoginFormBase.root(), Login.root(),
Cancle.GET() all call get_valid_transaction(). I'm trying to
understand the semantic differences between the two approaches.
As far as I can tell the only signficant difference is that
get_valid_transaction() also looks for the id in the referer,
otherwise it's almost the same logic.
What's the fundamental reason for the two approaches?
get_valid_transaction() can raise a ValueError for an expired
transaction but I don't see any logic that enforces that. Also if the
transaction does not exist it creates a new one, as far as I can tell
the only thing that will trigger the execption is if the UUID provider
cookie is absent.
Let's talk about the cookies in the transaction for a moment, a
Transaction has 2 cookies, the ipsilon_transaction_id cookie is
obvious. But there is also a cookie whose name is a UUID and value is
the provider. What is this being used for? The only reference I see to
it are in the AuthenticateRequest._preop() methods. It checks to see
if the UUID cookie value (provider) matches the handler processing the
request.
Why is the transaction provider check necessary? All it does is log a
debug message.
Why isn't the logic to compare the UUID cookie value to the provider
inside the Transaction constructor or get_valid_transaction?
It seems like we have a lot of cut-n-paste duplicated code for
transactions and/or code that differs only insignificantly that could be
parameterized instead. Any reason why this code isn't in one common
shared utility?
A few more questions but related to the unique_data storage system
that transactions utilize.
Do I understand correctly that the unique_data system stores data
under a key whose value is a dict and that each time save_unique_data
is called the passed in dict is used to update the stored dict, thus
the stored dict accumulates new key/value pairs on each save (and or
replaces the value of an existing key). Did I get that right?
If that correct then isn't there a possible problem with name
collisions by components that store into the transaction but are
unware of the names in use? For example the transaction stores under
the name "cookie", that's a pretty generic name, what prevents someone
else from using the same name and corrupting the transaction data?
If the tranaction object where we expect to store *all* data unique to
an operation? It might seem like there is an obvious answer because of
the assumption occur across multiple requests. But there are some
operations that are handled in only a single request, there is no
logical need for a transation object in this case, other than it's
just a handly place to hang data that all components in the code can
utilize. Is that the thinking?
--
John
9 years, 2 months
REST API pages
by Rob Crittenden
Simo, need some input on you on how you think the REST pages should be
registered.
I've tried a few methods and haven't been really happy with any of them.
Here is what I've tried.
1. Make the REST pages a subclass of AdminPage. It really is in a way
because they are for administration. The problem I had was with the
template and Page abstraction. It doesn't really fit and setting lots of
stuff to None just seems wrong.
2. Make a whole new set of classes similar to AdminPage but using
different subclassing so it doesn't originate at Page. This adds a whole
ton of new code for a fairly small feature (at least right now we're
just talking a small part of saml2).
3. Make REST pages a hybrid, subclassing from AdminPage but doing all
the plugin loading manually, so self.rest = blahblahblah(). Pretty muich
same issues as #2.
4. I considered abstracting AdminPage further to make it support both
Page and REST but never started coding that one.
I keep going back and forth on things. These are administrative mount
points, so AdminPage seems natural, but they aren't pages, so not so
much. They require admin access, so AdmiNPage seems natural, but bleh on
the other parts.
I think that pretty much any option is going to require a fair bit of
grunt coding of classes to make it work (lots of code, probably not a
ton of effort).
Rather than choosing one and getting picked apart at review, lets come
up with some plan in advance :-)
rob
9 years, 2 months
authenticating to ipsilon using persona
by Fraser Tweedale
Hi ipsilon@,
I was wondering something about Ipsilon... I know Ipsilon can be an
identity provider for users in an IdM/LDAP on a number of federation
protocols including Persona.
Can Ipsilon be used by a Service Provider to authenticate *external*
users via Persona, OpenID, etc? The advantage of this would be that
all of the authentication logic for the various protocols resides in
one place (Ipsilon) and multiple SPs can use Ipsilon.
I had a quick look at the code and saw the Persona IdP logic, but
nothing related to verifying Peronsa/BrowserID backed assertions.
But perhaps I overlooked something and Persona already does this.
Cheers,
Fraser
9 years, 2 months