OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[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]