Hey Alex,
Thanks for the feedback. Triplesec is a brilliant (Nice foresight), and I'm sure it will
get plenty of traction. One of my goals, in addition to freeing up more time to
contribute, is to understand it better so that when bouncing around on SSO mailing lists,
Tuscany (Policy management), etc. and see posts that might be related, I can say
"Check out Triplesec!". So tying it to usage scenarios like Google apps ,etc.
helps. In general most of the discussions I see are scenarios where someone has a
resource:
So it sounds like Google (Hypothetically) would most likely front Triplesec with Google
SSO, so Google SSO would use their AuthenticationHandler to authenticate Tina against her
account stored in ADS on the host triplesec.google.com. Then if that works out Tina gets
a ticket and gets to see her mail, spreadsheets, etc. at
host1.google.com/tina/spreadsheet?sheet=firstOne. Then Tina wants to see Joe's spreasheet
on host2.google.com/joe/spreadhset?sheet=joeSheet. So she clicks on that link.
host2.google.com gets Tina's sso cookie, and sends it to triplesec at
http://triplesec.google.com/authorization. Triplesec then checks the cookie and figures
out that it's Tina. Then it looks to see if Tina is in any of the groups that Joe
configured for the resource host2.google.com/joe/spreadhset?sheet=joeSheet. It sees that
Tina is indeed in the group, and sends a "Goahead" back to host2.google.com
saying send the resource, but make it read only.
In this type of scenario there would be a triplsec application filter that's
responsible for intercepting any requests made to the application (Server
spreadsheet application host), asking triplesec first if it's cool, and then
notifying the application of the triplesec authorization decision + any policy
constraints with respect to read, write, etc. Another aspect to it would be
dividing up the spreadsheet into sections. So Tina's authorization scope is
rows 1-5, and the rest of the spreadsheet is off limits...Which would require a
custom schema and authorization protocol, since it could be for lines 1-5 in
the spreadsheet, or slides 10-15 in the presentation application, etc.
OK - I'll stop there before I exceed googles mail size limit. I know you have sore wrists, etc. and greatly appreciate your dedication, so I tried to write as much as possible, in order to make it easy to comment.
Thanks,
- Ole
Alex Karasulu wrote:
Sorry for taking so long to respond I was dealing with a computer
catastrophe here for the past few days. More inline ...
On Feb 7, 2008 1:21 PM, Jesse McConnell <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
oh goodie, I have been waiting/lurking for some triplesec material
to crop up on this list since talking to david jencks at apachecon :)
I've been researching this for some time now (years) and I think the
schema for what we need in terms of the proper resolution to support
things like exposing policy via XACML and other policy expression
languages is pretty clear.
I would like to carve out a IETF draft specifically for this and
implement it here after having experimented with previous ideas in
Triplesec.
We've had many conversations with David on this list and I think we have
resolved some of our differences. It's only a matter now of siting down
and writing the schema.
in general there seems to be a shortage of actual open source role
based access control implementations so any offering in this regard
is good for triplesec and apacheds...I am hoping to swap out the
rbac implementation in redback (underlying user manglement solution
in use for continuum and archiva in mavenlands) with something a
little more standard and bullet proof.
Excellent. Your feedback will be most welcome and furthermore your
welcome to join us in Triplesec development if you find the time and are
interested.
On Feb 7, 2008 12:12 PM, Ole Ersoy <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hey Guys,
I was just reading through this article:
http://news.yahoo.com/s/nm/20080207/wr_nm/google_team_software_dc_1
and thought of triplesec. From 50K feet (OK maybe a little
lower) it sounds like Triplesec would be the ideal solution for
managing (create, read, write, execute, etc.) groups of
collaborators working on different documents.
Absolutely. We have been trying to get there but there are a few things
we need in ADS to support efficient application of policy in an ACDF
(Access Control Decision Function).
We are also thinking of using this schema in combination with another
authorization schema based on subschema in addition to the basic
authorization supported by ApacheDS today.
Also I think this is a great place for us to collaborate with the
OpenLDAP folks like Howard et. al.
All the users could be stored in ADS, along with the locations
of user documents, and the users could then just assign
permissions using the role based hierarchy discussed.
Yep that's the idea. We'll get there. We just need more hands on
people, time and support.
This seems to be a hot area for Google Apps, and thus
presumably others will follow suit, and if triplesec were
positioned as the right solution for this it could be good for
all of ADS as a whole.
Indeed.
Thanks for the post Ole & Jesse. Let me know if you guys have any other
questions or are interested in chipping away at some of our issues.
Regards,
Alex
