<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="ace-line" id="magicdomid200"><span
class="author-a-ek7umuz65zz86z0z78zz68zsn52h">In support of </span></div>
<div class="ace-line" id="magicdomid203"><span
class="author-a-ek7umuz65zz86z0z78zz68zsn52h url"><a
href="https://blueprints.launchpad.net/keystone/+spec/pluggable-remote-user">https://blueprints.launchpad.net/keystone/+spec/pluggable-remote-user</a></span></div>
<div class="ace-line" id="magicdomid206"><span
class="author-a-ek7umuz65zz86z0z78zz68zsn52h url"><a
href="https://blueprints.launchpad.net/keystone/+spec/split-identity">https://blueprints.launchpad.net/keystone/+spec/split-identity</a></span></div>
<div class="ace-line" id="magicdomid209"><span
class="author-a-ek7umuz65zz86z0z78zz68zsn52h url"><a
href="https://blueprints.launchpad.net/keystone/+spec/federation">https://blueprints.launchpad.net/keystone/+spec/federation</a></span></div>
<div class="ace-line" id="magicdomid211"><br>
</div>
<div class="ace-line" id="magicdomid859"><span
class="author-a-ek7umuz65zz86z0z78zz68zsn52h">We need to figure
out what we are going to do when the Identity Backend is read
only. We need to be able to map the usersIds</span></div>
<div class="ace-line" id="magicdomid409"><br>
</div>
<div class="ace-line" id="magicdomid1022"><span
class="author-a-ek7umuz65zz86z0z78zz68zsn52h">There are three
identified options:</span></div>
<div class="ace-line" id="magicdomid155"><br>
</div>
<div class="ace-line" id="magicdomid456">
<ol start="1" class="list-number1">
<li><span class="author-a-ek7umuz65zz86z0z78zz68zsn52h">Have a
remapping table</span></li>
</ol>
</div>
<div class="ace-line" id="magicdomid457">
<ol start="2" class="list-number1">
<li><span class="author-a-ek7umuz65zz86z0z78zz68zsn52h">Try
domains one by one (exclusively for lookup, never attempt
auth)</span></li>
</ol>
</div>
<div class="ace-line" id="magicdomid458">
<ol start="3" class="list-number1">
<li><span class="author-a-ek7umuz65zz86z0z78zz68zsn52h">Agree
on a naming convention so that we can deduce domain from the
name </span></li>
</ol>
</div>
<div class="ace-line" id="magicdomid464"><br>
</div>
<div class="ace-line" id="magicdomid1020"><span
class="author-a-ek7umuz65zz86z0z78zz68zsn52h">Option 3 is
preferred, as it allows OpenStack to use the pre-existing Unique
identifiers. Since public clouds will have to support
arbitrary email -> domain mappings or oauth, it might not be
simple to map this to a SQL backend implementation. However,
for those instances, it should be possible to use the email
address as username and continue to use the UUID as the User Id.</span></div>
<div class="ace-line" id="magicdomid824"><br>
</div>
<div class="ace-line" id="magicdomid1018"><span
class="author-a-ek7umuz65zz86z0z78zz68zsn52h">Is there any
compelling reason to create a "shadow" entry in Keystone? It
seems that any temporary entries should be role assignments, not
user entries.<br>
</span></div>
<div class="ace-line" id="magicdomid444"><br>
</div>
<div class="ace-line" id="magicdomid858"><br>
</div>
<div class="ace-line" id="magicdomid857">
<div class="ace-line" id="magicdomid1050"><span
class="author-a-ek7umuz65zz86z0z78zz68zsn52h">Written up
here: </span><span
class="author-a-ek7umuz65zz86z0z78zz68zsn52h url"><a
href="https://etherpad.openstack.org/mapping-user-ids">https://etherpad.openstack.org/mapping-user-ids</a><br>
<br>
<br>
</span></div>
</div>
</body>
</html>