Dimitri, thanks for the reply! Pls forgive my lateness.

I fear I am not currently up to fighting with MS Outlook to convince it to let 
me respond inline. It wants to block quote your entire message and if I type in 
the middle it keeps the "quoted" style.

In any case:

#1] Making small things work first and accumulating functionality is definitely 
the way to go. If it were simple and straightforward, everyone would be doing 
it already.

#2] I looked at "views" (Ticket 3979 as well as 
http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust). I 
think I follow most of it (a default view which applies to the whole domain, 
custom views which may be applied to particular targets). +1 +1 +1. One concern 
I have is that the design page seems to be written around a single upstream 
source (trust with AD). What happens if there are many "upstreams"?  All in 
all, though, it sounds like my current RFE is a duplicate of views. If we could 
add in my use case to the Views ticket/design, we can close mine out.

#3] Kerberos based auto provisioning will fall apart if the authentication path 
cannot be walked by the client (not the FreeIPA server). When I'm sitting in my 
office, I can see my KDC as well as the collaboration environment, and I can 
walk the path. However, if I cannot convince my CIO to poke a hole in the 
firewall so that FreeIPA in the collaboration domain can get to the internal AD 
(to query attributes, etc), then an AD trust is not possible and a vanilla 
Kerberos trust is all that is available. Kerberos-trust based auto-provisioning 
may be able to handle situations that AD trusts can't. By and large, I need my 
boxes to know my username, and could care less if they know my givenName, sn, 
mail, telephoneNumber, etc. As long as FreeIPA can synthesize a uidNumber for 
me in the absence of an SID, the rest is gravy.

#4] One user/Many Accounts. This is an unavoidable reality. Also, there's a 
namespace collision issue here. My Kerberos cname@crealm is 
bnordg...@ds.fs.fed.us<mailto:bnordg...@ds.fs.fed.us> as issued from my AD. My 
SAML uid is "bnordgren@fs" from https://www.eauth.usda.gov/Login/login.aspx. My 
Google OpenID is bnordgren from "wherever". There is also a "bnordgren" from a 
university out of SLC, Utah. I occasionally get mis-addressed email for him. 
Typically spam, but once from his mom. Fundamentally, whenever multiple domains 
are consolidated into a single namespace (as is already a use case for views), 
one typically tries to avoid username collisions just as vigilantly as they try 
to avoid uidNumber collisions. What is needed here is a method for the users to 
override the default collision avoidance such that they allow all of their 
accounts to be mapped onto their One True Username for the domain. In the 
spirit of point #1, implementing collision avoidance will be required for 
views, so it needs to happen now even without external collaboration. Figuring 
out how to let users override it can happen in the future.


From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Dmitri Pal
Sent: Wednesday, May 14, 2014 4:13 PM
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] External collaboration edits

On 04/19/2014 07:46 PM, Nordgren, Bryce L -FS wrote:
I've run out of time for today, but the external collaboration pages are slowly 


Dimitri observed that my RFE page was too long. I observe it also has too much 
stuff unrelated to the actual meat of the RFE. So I factored out most of the 
Kerberos stuff into a different page. I also tried to focus the RFE to just 
creating entries in LDAP for external users so they can: a] participate in 
POSIX groups; and b] have locally-defined POSIX attributes.


This is where all the Kerberos stuff went. I also added  in "Option A" from 
Petr's email. Option B will come along later, when I pick this up again. 
Mechanism three has more to do with Ipsilon than IPA, and basic functions 
required of the Ipsilon gateway server are articulated there (regardless of the 
particular authentication method.)

Send comments to the list. I really appreciate Option A! Send more stuff I 
didn't think of.


I finally read the pages, sorry for the delay. great writeup!

Here are some comments.

1) You are right that we need to have a record in IPA to be able to have a DN 
and take over some of the posix attributes. We already have this use case and 
this is a high priority. We call it views: 
Once this is implemented we will have mechanism to have a local entry without 
credential for the external user.
2) The second issue is provisioning as automatic as possible. And this is where 
there will be some issues.
If we want to leverage Kerberos trusts then two things should happen:
a) the trust should first be established
b) the home realm should be accessible for the KDC in the collaboration domain.
This rises practical operational questions about what is the home domain. If 
the home domain is another collaboration domain then user is natively have been 
created in that domain and has his credential in that domain. Hm but that 
violates the idea that the collaboration domains have external 
"auto-provisioned users". If the home domain is the internal domain than most 
likely the cross forest trust can't be established because admin of the 
internal domain would not want to expose his domain to somebody's external 
domain on the internet.
So IMO the kerberos based auto-provisioning falls apart.

However if we use a gateway that would allow a person to self register and use 
technologies similar to OpenID then we would be able to create his own account. 
The gateway would check that the user is from some trusted source that is 
configured for that domain. We would have to figure that part out. But IMO this 
component is external to IPA. It is a similar gateway to Ipsilon. I suspect 
that as we move forward Ipsilon will transform from an IdP server to being a 
collection of "gateway services". One would be able to deploy IdP instances, 
Kerberos -> cert service, account registration service etc.

This would rely on some of the functionality in IPA but can evolve 
IMO if we go this path and you are interested in contributing to this effort we 
can start prototyping such service.
We can start simple: create a service that allows one to authenticate using 
google or facebook and once user authenticated agains one of them call an ipa 
user-add against IPA.
That would be a good first step towards what you want to accomplish.
Then it can be enhanced to redirect to an external IdP (Ipsilon). Then the 
setup will be:

* User connects to the self registration portal.
* Portal reditrects him to the IdP that is configured for the portal
* IdP performas an authentication against user home domain and creates assertion
* Assertion is presented to the registration portal
* The portal gets user infor from the assertion and adds a user

It also seems that OpenID connect might be quite relevant here.
So exploring how it can be used in in conjunction with registration portal 
would be another path.

3) The problem of the credential yet stays open. If the user can be created in 
different ways it might not be quite easy for the user to know or remember that 
he must use his kerberos/Google/facebook or other credential wit ha specific 
domain. May be we should consider creating a full user also with a password or 
OTP token to access the collaboration domain. Then user would always know that 
he needs to use his token. I wonder if actually just OTP would be a good option 
in this case. It can be provisioned to the freeOTP app at the moment of the 
user registration.



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




Thank you,

Dmitri Pal

Sr. Engineering Manager IdM portfolio

Red Hat, Inc.
Freeipa-users mailing list

Reply via email to