comanage-dev - Re: [comanage-dev] Action Items: COmanage Call 2-Oct-09
Subject: COmanage Developers List
List archive
- From: Dan Pritts <>
- To: "Michael R. Gettes" <>
- Cc: CoMaNaGe-DeV <>
- Subject: Re: [comanage-dev] Action Items: COmanage Call 2-Oct-09
- Date: Sat, 3 Oct 2009 23:44:39 -0400
first, i agree that it is not comanage that would need to do this,
but rather the applications themselves. Or rather, applications
would need to be support it, and once that was done comanage would
need to know how to provision them appropriately.
as to how to engineer the applications, sure it's possible. The apps
just have to be aware that there are multiple possible authentication
methods, and know what to do with each.
For example, couldn't a (to be written) sasl backend accept a SAML
assertion?
whether this is worth putting effort into is of course another question
thanks
danno
On Sat, Oct 03, 2009 at 11:52:17AM -0400, Michael R. Gettes wrote:
> If this is what is being requested... this is not possible. It has
> nothing to do with COmanage per se, rather how applications and the
> infrastructure work. Tell me how we would engineer these apps to
> handle both LDAP (or other) and Federated login? Very few apps tend
> to work
> this way, if any. The apps are enabled by federated or loosely coupled
> access (in the case of apps like dimdim/openmeetings they are accessed
> not thru authentication but by affiliation and controlling how it is
> accessed).
>
> Now, if there was an IdP for COmanage and it handled local
> authentication
> then this would solve the problem - but, this is just federation. I
> don't
> see it the job of COmanage to provide an IdP to handle local accounts -
> except for the case where we have discussed adding an IdP to enable a
> CO to participate in the attribute economy.
>
> However, I am always willing to be educated for things I don't yet
> understand.
>
> /mrg
>
> On Oct 3, 2009, at 11:40, RL 'Bob' Morgan wrote:
>
> >
> >>>[AI] (SteveO) will ask Michael about the ability of a COmanage
> >>>instance to
> >>>accept logins from both federated and non-federated sources.
> >>
> >>huh? I don't understand this. People who do not have federated
> >>identity can get an id from ProtectNetwork - but is this what is
> >>being
> >>asked? Clarity appreciated.
> >
> >I wasn't on the call so I'm just guessing, but I suppose that in some
> >situations where people want to go Cm, they'll have existing local,
> >probably LDAP-based, accounts they want to use while transitioning
> >to the
> >brave new fully-federated world. So it would be good for Cm to work
> >with
> >local accounts too, as well as federation. But probably not high-pri.
> >
> > - RL "Bob"
> >
>
danno
--
Dan Pritts, Sr. Systems Engineer
Internet2
office: +1-734-352-4953 | mobile: +1-734-834-7224
Fall 2009 Internet2 Member Meeting, October 5-8
Hosted by the University of Texas at San Antonio and LEARN
http://events.internet2.edu/2009/fall-mm/
- Action Items: COmanage Call 2-Oct-09, Emily Eisbruch, 10/02/2009
- Re: [comanage-dev] Action Items: COmanage Call 2-Oct-09, Michael R. Gettes, 10/02/2009
- Re: [comanage-dev] Action Items: COmanage Call 2-Oct-09, RL 'Bob' Morgan, 10/03/2009
- Re: [comanage-dev] Action Items: COmanage Call 2-Oct-09, Michael R. Gettes, 10/03/2009
- Re: [comanage-dev] Action Items: COmanage Call 2-Oct-09, Dan Pritts, 10/03/2009
- Re: [comanage-dev] Action Items: COmanage Call 2-Oct-09, Michael R. Gettes, 10/03/2009
- Re: [comanage-dev] Action Items: COmanage Call 2-Oct-09, RL 'Bob' Morgan, 10/03/2009
- Re: [comanage-dev] Action Items: COmanage Call 2-Oct-09, Michael R. Gettes, 10/02/2009
Archive powered by MHonArc 2.6.16.