[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep] [RS Issue] Internal Vs. External Users
Not exactly David. SAML is not the whole story. How does a SAML assertion parlay into a list of users when a registry client makes a request asking for User instances? David Webber (XML) wrote: >Farrukh, > >OK makes sense - and therefore Adobe should be >implementing SAML 2.0 between their proprietary >registration server and the registry - and that then >should put them in alignment?! > > ; -) > >DW > >----- Original Message ----- >From: "Farrukh Najmi" <Farrukh.Najmi@Sun.COM> >To: <regrep@lists.oasis-open.org> >Sent: Saturday, January 22, 2005 5:48 PM >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_workgrou >>> >>> >p > > >>>> >>>> >>>.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_workgrou >>> >>> >p > > >>>> >>>> >>>.php. >>> >>> >>> >>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >>> >>-- >>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/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]