<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 06/07/2014 05:21 PM, Nordgren, Bryce
L -FS wrote:<br>
</div>
<blockquote
cite="mid:82E7C9A01FD0764CACDD35D10F5DFB6E6D446D@001FSN2MPN1-044.001f.mgd2.msft.net"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<meta name="Generator" content="Microsoft Word 14 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:"Consolas","serif";
color:black;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">Dimitri, thanks
for the reply! Pls forgive my lateness.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">In any case:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">#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.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">#2] I looked at
“views” (Ticket 3979 as well as
<a moz-do-not-send="true"
href="http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust">http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust</a>).
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.</span></p>
</div>
</blockquote>
<br>
We start with AD views. When we get to IPA to IPA trusts we see how
much of this applicable and or reusable.<br>
<br>
<blockquote
cite="mid:82E7C9A01FD0764CACDD35D10F5DFB6E6D446D@001FSN2MPN1-044.001f.mgd2.msft.net"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">#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.</span></p>
</div>
</blockquote>
<br>
You might be able to convince him to do SAML federation and stand up
an IdP. This is why we are working on Ipsilon.<br>
<br>
<blockquote
cite="mid:82E7C9A01FD0764CACDD35D10F5DFB6E6D446D@001FSN2MPN1-044.001f.mgd2.msft.net"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">#4] One
user/Many Accounts. This is an unavoidable reality. Also,
there’s a namespace collision issue here. My Kerberos
cname@crealm is
<a moz-do-not-send="true"
href="mailto:bnordgren@DS.FS.FED.US">bnordgren@DS.FS.FED.US</a>
as issued from my AD. My SAML uid is “bnordgren@fs” from
<a moz-do-not-send="true"
href="https://www.eauth.usda.gov/Login/login.aspx">https://www.eauth.usda.gov/Login/login.aspx</a>.
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.
</span></p>
</div>
</blockquote>
<br>
This is a standard problem of identity mapping. It is not solvable
in general and has to be solved in the context of every namespace.<br>
In our case we use FQ names so we are pretty much guaranteed to have
unique names. With Kerberos trusts one can just let external
principal be and wonder around. If you do SAML you would have to
create local principal and probably assign his external name that
came from SAML as an alias. Kerberos supports aliases so it is the
question of implementing it.<br>
<br>
I think we are going into the right direction with our efforts, it
is just the question of time and demand.<br>
As time goes more and more interoperable solutions would be needed
so the demand for identity "collaboration" will become more urgent.
Right now we have many fishes to fry and cats to skin. <br>
<br>
Stay tuned.<br>
<br>
<blockquote
cite="mid:82E7C9A01FD0764CACDD35D10F5DFB6E6D446D@001FSN2MPN1-044.001f.mgd2.msft.net"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Bryce<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in
0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">
<a class="moz-txt-link-abbreviated" href="mailto:freeipa-users-bounces@redhat.com">freeipa-users-bounces@redhat.com</a>
[<a class="moz-txt-link-freetext" href="mailto:freeipa-users-bounces@redhat.com">mailto:freeipa-users-bounces@redhat.com</a>]
<b>On Behalf Of </b>Dmitri Pal<br>
<b>Sent:</b> Wednesday, May 14, 2014 4:13 PM<br>
<b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:freeipa-users@redhat.com">freeipa-users@redhat.com</a><br>
<b>Subject:</b> Re: [Freeipa-users] External
collaboration edits<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On 04/19/2014 07:46 PM, Nordgren, Bryce
L -FS wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">I’ve run out of time for today, but the
external collaboration pages are slowly evolving.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><a moz-do-not-send="true"
href="http://www.freeipa.org/page/External_Users_in_IPA">http://www.freeipa.org/page/External_Users_in_IPA</a><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><a moz-do-not-send="true"
href="http://www.freeipa.org/page/Collaboration_with_Kerberos">http://www.freeipa.org/page/Collaboration_with_Kerberos</a><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">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.)<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Send comments to the list. I really
appreciate Option A! Send more stuff I didn’t think of.
<o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Times New
Roman","serif""><br>
Hello,<br>
<br>
<br>
I finally read the pages, sorry for the delay. great
writeup!<br>
<br>
Here are some comments.<br>
<br>
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:
<a moz-do-not-send="true"
href="https://fedorahosted.org/freeipa/ticket/3979">https://fedorahosted.org/freeipa/ticket/3979</a><br>
Once this is implemented we will have mechanism to have a
local entry without credential for the external user.<br>
2) The second issue is provisioning as automatic as
possible. And this is where there will be some issues.<br>
If we want to leverage Kerberos trusts then two things
should happen: <br>
a) the trust should first be established <br>
b) the home realm should be accessible for the KDC in the
collaboration domain.<br>
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. <br>
So IMO the kerberos based auto-provisioning falls apart.<br>
<br>
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.<br>
<br>
This would rely on some of the functionality in IPA but
can evolve independently.<br>
IMO if we go this path and you are interested in
contributing to this effort we can start prototyping such
service.
<br>
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.<br>
That would be a good first step towards what you want to
accomplish.<br>
Then it can be enhanced to redirect to an external IdP
(Ipsilon). Then the setup will be:<br>
<br>
* User connects to the self registration portal.<br>
* Portal reditrects him to the IdP that is configured for
the portal<br>
* IdP performas an authentication against user home domain
and creates assertion<br>
* Assertion is presented to the registration portal<br>
* The portal gets user infor from the assertion and adds a
user<br>
<br>
It also seems that OpenID connect might be quite relevant
here.<br>
So exploring how it can be used in in conjunction with
registration portal would be another path.<br>
<br>
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.<br>
<br>
<br>
<br>
Thanks<br>
Dmitri <br>
<br>
<br>
<o:p></o:p></span></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Bryce<o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Times New
Roman","serif""><br>
<br>
<br>
<br>
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.
<br>
<br>
<br>
<o:p></o:p></span></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>Freeipa-users mailing list<o:p></o:p></pre>
<pre><a moz-do-not-send="true" href="mailto:Freeipa-users@redhat.com">Freeipa-users@redhat.com</a><o:p></o:p></pre>
<pre><a moz-do-not-send="true" href="https://www.redhat.com/mailman/listinfo/freeipa-users">https://www.redhat.com/mailman/listinfo/freeipa-users</a><o:p></o:p></pre>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Times New
Roman","serif""><br>
<br>
<br>
<o:p></o:p></span></p>
<pre>-- <o:p></o:p></pre>
<pre>Thank you,<o:p></o:p></pre>
<pre>Dmitri Pal<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Sr. Engineering Manager IdM portfolio<o:p></o:p></pre>
<pre>Red Hat, Inc.<o:p></o:p></pre>
</div>
</div>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.</pre>
</body>
</html>