[...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).

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).

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.


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 

Freeipa-users mailing list

Reply via email to