RE: [regrep] [RS Issue] Internal Vs. External Users

["Chiusano Joseph" <chiusano_joseph@bah.com>]

<Quote>
As I said in response to Joe's message on this thread I think the only
interfaces related to IdentityProvider / AuthenticationAuthority we need
to define are those defined by SAML 2 SSO protocols that are already
being used in the 3.0 specs and that we should not specify a different
interface. Thanks.
</Quote>

Read my lips: No New Interfaces!!!! ;)

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 5:35 PM
> To: David Webber (XML)
> Cc: Matthew MacKenzie; Chiusano Joseph; regrep@lists.oasis-open.org
> Subject: Re: [regrep] [RS Issue] Internal Vs. External Users
> 
> 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.
> >  
> >
> For those not familiar with OMAR it is the internal name of 
> the freebXML Registry project.
> 
> >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.
> >  
> >
> As I said in response to Joe's message on this thread I think 
> the only interfaces related to IdentityProvider / 
> AuthenticationAuthority we need to define are those defined 
> by SAML 2 SSO protocols that are already being used in the 
> 3.0 specs and that we should not specify a different 
> interface. Thanks.
> 
> >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/l
> eave_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/l
> eave_workgroup.php.
> >  
> >
> >>
> >>    
> >>
> >
> >
> >  
> >
> 
> 
> --
> Regards,
> Farrukh
> 
>