<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
What you are describing MAKES ZERO SENSE. From your document:<br>
<br>
"A token is created when an user reaches the path <code>/secret-store/v1/tokens/create</code>
via GET (or passing the username and
password as Basic authentication via POST) and stored into a
Cassandra data store:"<br>
<br>
You are doing EXACTLY what the direct grant REST api does except you
are using basic auth. I still don't see the purpose of this
service.<br>
<br>
<div class="moz-cite-prefix">On 1/20/2016 10:57 AM, Juraci Paixão
Kröhling wrote:<br>
</div>
<blockquote cite="mid:569FAE4D.6030401@kroehling.de" type="cite">
<pre wrap="">Direct grants require the client to have access to an user's
credentials. On our specific case, having plain text access to the
account credentials are not viewed as very secure by sysadmins. So,
issuing those tokens and making them individually revokable make sense.
On 20.01.2016 16:32, Bill Burke wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I honestly don't get why you are doing this. I assume you are familiar
with direct grants. Why aren't these enough? Its just a REST call to
keycloak to obtain a token. Honestly, this seems ridiculous.
On 1/20/2016 9:15 AM, Juraci Paixão Kröhling wrote:
</pre>
<blockquote type="cite">
<pre wrap="">For Hawkular, we were in the need of a simplified way for a REST client
to communicate with our backend. After discussing this with Stian, we
started the "secret-store" module, which was just spun off of Hawkular
into a "standalone" project.
Secret Store is a module for scenarios where the whole OAuth procedure
might be undesirable or not feasible on the client side.
The Secret Store has two sides:
1) a REST endpoint to create opaque tokens backed by OAuth Offline
Tokens composed of a key and secret;
2) An Undertow filter/Proxy server, that translates the opaque tokens
into OAuth bearer tokens, rewriting the incoming request. To your
backend, it's transparent whether an opaque token or a proper OAuth
token was used.
More info here: <a class="moz-txt-link-freetext" href="https://github.com/jpkrohling/secret-store">https://github.com/jpkrohling/secret-store</a>
- Juca.
_______________________________________________
keycloak-user mailing list
<a class="moz-txt-link-abbreviated" href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-user">https://lists.jboss.org/mailman/listinfo/keycloak-user</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">_______________________________________________
keycloak-user mailing list
<a class="moz-txt-link-abbreviated" href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-user">https://lists.jboss.org/mailman/listinfo/keycloak-user</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Bill Burke
JBoss, a division of Red Hat
<a class="moz-txt-link-freetext" href="http://bill.burkecentral.com">http://bill.burkecentral.com</a></pre>
</body>
</html>