[Freeipa-users] External collaboration edits

[Sumit Bose]

On Mon, Jun 16, 2014 at 07:41:08PM +0000, Nordgren, Bryce L -FS wrote:
> [...talking about views...]
> 
> > It's not only about AD, but use-case and examples in the design page
> > currently all refer to AD. The key is to find a unique reference to the
> > upstream object which in the AD case is obviously the SID. In a previous
> > version of the page there were a bit more details who the original/upstream
> > objects can be referenced, e.g. it can a fully qualified name or Kerberos
> > principal.
> 
> Can views handle the case when there is no upstream object? Or when the upstream attribute store is not published as a searchable database (which is almost "no upstream object")? I'd very much like to see these as explicit use cases for views.
> 
> Case one would represent vanilla Kerberos trusts, or the quite likely scenario where an external collaboration domain is separated from corporate AD by a firewall. (e.g., institutional AD can provide authentication via trust for users on the corporate network, but not attributes).

I think this can be done. It is about how the reference key is
evaluated. E.g. if the key is ':KRB5:user at EXAMPLE.COM' in the default
view SSSD can create a user object in its cache with the data given in
the view and where the user name is equal to the Kerberos principal
name (so far we said that we do not want to allow to overwrite the user
name in views to avoid confusion). Since the object is now in the SSSD
cache it is available in the IPA server, on IPA clients with SSSD via
extdom plugin and to legacy clients via the compat tree.

> 
> Case two would represent authentication sources such as SAML. Views would need to be the mechanism by which the gateway caches attributes in FreeIPA (after inspecting SAML assertions).

I think we are already doing similar things with the MS-PAC. If
configured SSSD will intercept the PAC, decode it and store data from
the PAC in the cache. This currently happens during authentication on
the client hence this data is directly available on the IPA client and
is not distributed by the IPA server. Would this work for you use case
or do you need the data on IPA clients where the user never
authenticated as well?

> 
> Finally, one functional requirement for views may be that the view needs to support a many-to-one "authentication method" to "identity attributes" mapping. For instance, an employee sitting at their desk may log into their server in the collaboration network via SSO (hence, their AD account). Soon this same user may also walk over to the console on the collaboration network and need to use some other Ipsilon-gateway-enabled credentials. These two credentials may need to be mapped to a single user identity. This may not be functionality which needs to be implemented first, but it does perhaps suggest that krbPrincipal may not always be single valued. This may be something which deserves an honorable mention on the RFE page as it impacts the assumptions coders can make.

I wonder if you mean that the reference in the user views may not always
be single valued ?

Thank you very much for your input. I plan to update the design page
during the next days. I hope you don't mind if I add your suggestions in
a 'Next step/Future Enhancements' section because I would prefer to get
the AD use case implemented and included in the IPA and SSSD trees
first.

bye,
Sumit

> 
> Thanks,
> Bryce
> 
> 
> 
> 
> This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.