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


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]