directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <ole.er...@gmail.com>
Subject Re: Google Team Edition and Triplesec
Date Sat, 09 Feb 2008 19:05:26 GMT
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 <jmcconnell@apache.org 
> <mailto:jmcconnell@apache.org>> 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 <ole.ersoy@gmail.com
>     <mailto:ole.ersoy@gmail.com>> 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
> 

Mime
View raw message