COmanage Developers List

["Michael R. Gettes" <>]

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"

Attachment: smime.p7s
Description: S/MIME cryptographic signature