[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep] [RS Issue] Internal Vs. External Users
Matthew MacKenzie wrote: > 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? +1 Mapping between SAML Assertion and Registry User is an important part of the SAML profile spec. And that is just what section 11.6.8 and table 8 in regrep-rs-3.0-draft-01 describes. Have we covered it adequately? If not what do you propose we need to change. > > > > 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. >> >> >> >> > > > 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]