[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep] [RS Issue] Internal Vs. External Users
David Webber (XML) wrote: >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? > > David, We have added single-signon support in the 3.0 specs based upon the SAML 2.0 SSO protocols which enables a registry to use an external Authentication Authority as long as it supports SAML 2. So I think we are already doing what you wisely suggest. >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. > > >>> >>> >>>> >>>> >>>> >>> >>> >>> >>> >> >> >> > > > > -- Regards, Farrukh
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]