<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 11/14/2014 09:32 AM, Don Waterloo
wrote:<br>
</div>
<blockquote
cite="mid:CAKrvkGd=BbwhK8H7BzVRTa9+G5JKkeRbPBpHU+664Kub8PObZA@mail.gmail.com"
type="cite">
<div dir="ltr">I have a system (juno/ubuntu 14.10) which currently
has keystone as the master of the
<div>universe for identity and authentication.
<div>By convention, each user of my system is also a tenant,
which is my intent to continue.</div>
<div>My system is used by a combination of our team members,
but also by 3rd parties</div>
<div>(e.g. we use it for training on our products).</div>
<div><br>
</div>
<div>I would like to make our saml system authoritative for
identity/auth for the</div>
<div>team members, but leave keystone authoritative for 3rd
parties.</div>
<div><br>
</div>
<div>Is there any documentation on someone who has such a
system, or, is there</div>
<div>any recommended best practises to follow?</div>
<div><br>
</div>
<div><br>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Mailing list: <a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a>
Post to : <a class="moz-txt-link-abbreviated" href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a>
Unsubscribe : <a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a>
</pre>
</blockquote>
So the intent is to split things up by domain. I would say that
your existing users should be in one domain (or multiple if they are
already) and Federated/SAML users would go into....limbo today, as
federated users are kindof domainless. I'd like to fix that (each
IdP has a minimum of one domain).<br>
<br>
The term "tenant" is kindof confusing here. I think what you are
saying is that each user of your system gets a default project
autoprovisioned for them. With Federation, you have to make sure
you don't provision for users with Valid Federated Identities but no
real relationship to your Cloud deployment.<br>
</body>
</html>