[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep] [RS Issue] Internal Vs. External Users
Matt, OK - I see that's another issue. Single sign-on. I guess we will need to extend the RIM to allow an external user ID and remote reference URL (along with potentially a certificate), in addition to our usual RIM metadata about person / org. That way - someone can provide a pointer to their credentials elsewhere. We would also need a store to hold those remote refernece URLs that we recognise as authentication authorities.... hmmm wonder if we can extend the notion of "organization" to incorporate type of registration authority? DW ----- Original Message ----- From: "Matthew MacKenzie" <mattm@adobe.com> To: "David Webber (XML)" <david@drrw.info> Cc: "Chiusano Joseph" <chiusano_joseph@bah.com>; "Farrukh Najmi" <Farrukh.Najmi@Sun.COM>; <regrep@lists.oasis-open.org> Sent: Sunday, January 23, 2005 5:18 PM Subject: Re: [regrep] [RS Issue] Internal Vs. External Users > David, > > The challenge is supporting external identity providers and integrating > data about users, groups and organizations into the rest of the > information model while honoring the fact that the external provider is > authoritative. > > Authentication is easy. We already support SAML-based SSO in our > implementation, and accept the user information as asserted via our > SAML/SSO system. The trick is in making User and Organization fully > virtual within the registry information model without mirroring or > otherwise replicating data from the identity provider. We've managed > it, but only because we happen to have a proprietary identity provider > that acts as a broker to our customer's actual identity provider(s) and > know how it works. The downside to this innovation on our part is that > you can't submit a User or Organization via the registry. We politely > inform the client that they must seek help from their Identity > provider's admin (typically someone, or a process than can access the > enterprise's LDAP/Active Directory). > > -Matt > > David Webber (XML) wrote: > > >Gentle folks - I see in the OMAR implementation we have > >the certificate management function. This is very useful > >and an excellent supporting service for Hermes and > >issuing of CPA certificates to partners, and more. > > > >Is this not the type of abstraction we need here? E.g. a > >neutral registry service that supports authentication > >and certificate management et al - but we do not > >need to specify exactly how this is done - just the > >types of service provided. > > > >That way implementers can provide extensions to > >their favourite directory services of choice - while > >at the same time allowing a higher level set of > >consistent services to be provided by and between > >registry(s) and associated services. > > > >Do we already have the makings of that service > >interface somewhere? > > > >Thanks, DW > > > >----- Original Message ----- > >From: "Matthew MacKenzie" <mattm@adobe.com> > >To: "Chiusano Joseph" <chiusano_joseph@bah.com> > >Cc: "Farrukh Najmi" <Farrukh.Najmi@Sun.COM>; <regrep@lists.oasis-open.org> > >Sent: Sunday, January 23, 2005 3:06 PM > >Subject: Re: [regrep] [RS Issue] Internal Vs. External Users > > > > > > > > > >>At the core of my comment is an understanding of facts in the enterprise > >>setting: An ebXML registry WILL NOT be an identity provider, unless of > >>course a very large software company decides to make a product and > >>successfully market it into many enterprise customers. I doubt this > >>would happen, so we need to be very specific in saying that Identity > >>management is not a registry function. By putting some kind of > >>abstraction in the specification, we still allow registries to support > >>being a minimal identity provider for small or pilot installations but > >>do not get in the way of serious enterprise installations either. > >> > >>I have yet to encounter a paying customer of ebXML registry that was > >>especially happy about having an extra user database to support. In > >>fact, since early days at XML Global, LDAP/ActiveDirectory integration > >>has been a top ask. > >> > >>-Matt > >>Chiusano Joseph wrote: > >> > >> > >> > >>>Farrukh, > >>> > >>>Is the bottom-line question here "should the registry should define an > >>>abstract PrincipalProvider service, and treat external and internal > >>>users equally as something that may or may not be managed by the > >>>registry?" rather than the way it is described in section 11.7? > >>> > >>>If so, I believe the definition/usage of a PrincipalProvider service > >>>should be left as an implementation choice. There may be implementations > >>>that use a registry only locally, and may not need to use external > >>>identity providers. On a related note, I would not consider the > >>>registry's management of users (a capability since v1) as synonymous > >>>with an identity provider in terms of what SAML and Liberty Alliance > >>>enable. > >>> > >>>Kind Regards, > >>>Joseph Chiusano > >>>Booz Allen Hamilton > >>>Strategy and Technology Consultants to the World > >>> > >>> > >>> > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM] > >>>>Sent: Saturday, January 22, 2005 11:38 AM > >>>>To: regrep@lists.oasis-open.org > >>>>Subject: [regrep] [RS Issue] Internal Vs. External Users > >>>> > >>>>Matt sent following comment on section 11.7 that describes > >>>>Internal Vs. > >>>>External Users. > >>>> > >>>>"This section exists, IMO, due to poor design. Why is there > >>>>even a concept of internal and external users and > >>>>organizations? The registry should define an abstract > >>>>PrincipalProvider service, and treat external and internal > >>>>users equally as something that may or may not be managed by > >>>>the registry." > >>>> > >>>>The registry historically since version 1 has served in the > >>>>roles of an Identity Provider (manages users) and an > >>>>Authentication Authority ( validates user credentials). Thus > >>>>a registry prior to version 3 allowed users to be stored > >>>>internal to the registry. > >>>> > >>>>With version 3 we allow the Identity Provider and > >>>>Authentication Authority functions to be provided by an > >>>>external SAML Authority such as an Access Manager service. > >>>>Depending upon deployment situations a registry MAY manage > >>>>users itself or leverage an external service to do so. > >>>> > >>>>This section is defining the behavior of how to handle cases > >>>>where a user is bweing managed by an external service rather > >>>>than the registry. > >>>> > >>>>If you have a specific proposal on how to address this issue > >>>>please share and we can review the details. Thanks. > >>>> > >>>>-- > >>>>Regards, > >>>>Farrukh > >>>> > >>>> > >>>>To unsubscribe from this mailing list (and be removed from > >>>>the roster of the OASIS TC), go to > >>>>http://www.oasis-open.org/apps/org/workgroup/regrep/members/le > >>>>ave_workgroup.php. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>To unsubscribe from this mailing list (and be removed from the roster of > >>> > >>> > >the OASIS TC), go to > >http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup .php. > > > > > >>> > >>> > >>> > >>To unsubscribe from this mailing list (and be removed from the roster of > >> > >> > >the OASIS TC), go to > >http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup .php. > > > > > >> > >> > >> > > > > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]