[keycloak-user] Data filtering in SQL
Geoffrey Cleaves
geoff at opticks.io
Sat Dec 1 11:17:17 EST 2018
Pedro,
I followed this thread with interest and have implemented your
recommendation to do data filtering via added claims. Do you know if it's
possible to add a JSON object to the claim? When I do
permission.addClaim('data.filter.userId', {"a":5});
I get: "data.filter": ["[object Object]"]
The protocol mapper scripting engine does allow adding JSON objects
correctly.
Regards,
Geoffrey Cleaves
On Fri, 9 Nov 2018 at 13:37, Pedro Igor Silva <psilva at redhat.com> wrote:
> On Thu, Nov 8, 2018 at 9:27 PM Byrd, Rob M <rmbyrd at dstsystems.com> wrote:
>
> > Pedro,
> >
> >
> >
> > That is helping my understanding some, thank you. I understand your
> > recommendations on dealing with separating the employee's Salary field in
> > my example too. Please see follow-up questions below.
> >
> >
> >
> > String resource attributes statically in keycloak:
> >
> > 2.1) I had been thinking of Resource as a *type* of resource to this
> > point not a specific instance. But now I don't see how your suggestion
> of
> > basically using the resource attribute to store a foreign key (ie. pet's
> > veterinarian) will work unless we are talking about each individual pet
> > instance being a keycloak resource. Similarly it was mentioned pet 1 and
> > pet 2 could have a meaningful Owner in keycloak, which again is making me
> > think that *instances* are being suggested to store along with
> > entity-relationships basically. So, should I instead be thinking of
> > keycloak resources as storing single instances of items in our system?
> >
> You should not think of Keycloak as storing *only* single instances, but
> with the necessary support to store single instances. That was my point
> when I mentioned that you can have a 1:1 or 1:N mapping between keycloak
> resources and your resources.
>
> The work to manage resources in Keycloak is quite trivial, keep them in
> sync with your real resources too. Performance of authorization requests
> for specific resources is quite good. It is a trade-off, the flexibility we
> give regarding governing access to individual resources vs the drawbacks of
> managing these resources in Keycloak. But again, you are not forced to use
> this approach, it really depends on your requirements. For instance, we
> support privacy through User-Managed Access (UMA), users are allowed to
> manage permissions for their own resources, share resources with others,
> allow/approve access to specific scopes/actions, and revoke access, where
> you have loosely coupled clients and resource servers, resource servers in
> control over the context that a permission should be granted, etc.
>
> I'm not pushing you to any specific solution but trying to clarify what we
> have, what we can do, what we can improve and how we could help "data
> filtering" use cases. Btw, thanks you and Dmitry for starting this.
>
> > 2.2) This relatively static storage of resources plus extra attributes
> > like foreign keys seems to basically push/duplicate our business model of
> > data into keycloak, to some degree, correct? And the more keycloak needs
> > to decide, the more gets duplicated into keycloak?
> >
> Not really, but true for data filtering. That is another
> point/drawback/concern that I tried to make when I said that data filtering
> is not among our target use cases. We can support it, but not something we
> discussed in the details like we are doing in this thread.
>
> Attributes can be used to define specific security related data associated
> with a resource which are not part of your business model. Thus, allowing
> you to keep your business model decoupled from security aspects that govern
> access to your resources.
>
> >
> >
> > Push claims:
> >
> > 2.3) The push claim alternative seems to be having application logic
> fetch
> > more context as needed for the permission evaluation. This might work
> okay
> > when going after a single entity or asking singular questions of the
> > application logic – but for lists, such as a user seeing his list of 100
> > transaction history records amongst the 1 million transaction history
> > records on the system, would a question be asked for each of the 1
> million
> > records, one at a time?
> >
> Pushing claims is not the correct approach to solve this problem.
>
> First, Keycloak is optmized to only evaluate policies for resources where
> the subject is the owner. So, considering that I decided to manage all 1
> million resources in Keycloak, each resource would have a user as the
> resource owner. During evaluation the policy engine is going to evaluate
> permissions fo 100 resources, not 1 million.
>
> You may ask now, would that scale ? Depends on how you obtain permissions
> from the server. If you are asking the server for all permissions and users
> can have 1 million resources over time, it won't scale. However, if you ask
> permissions for individual transactions or a small set of transactions, it
> will scale.
>
> >
> >
> > Post-filtering of records:
> >
> > 2.4) A use case I still seek clarification on is the "post-filtering of
> > records", which I was trying to get at with my previous question #5.
> > Stated in another way - say a financial database has 1 million
> transaction
> > records across thousands of users. Every user is allowed to see
> transaction
> > history records view, but only the ones they transacted. So, a single
> user
> > viewing all transactions of the transaction history feature/resource
> should
> > (obviously) only be able to see all HIS transactions, not all 1 million
> on
> > the database. Spring Security would have @PostAuth for this (though its
> > drawback is slow db performance on first query that does a db table scan
> > and brings back everything to the middle tier, which then inefficiently
> > whittles it down to just what pertains to the user). My question is what
> > ways would this post-filtering of records be handled in Keycloak? With
> > what I know so far, I am guessing at keycloak basic options:
> >
> > a) Have each of 1mil transaction records managed by Keycloak, add a
> > "creator" attribute for who instigated the transaction, and have that
> user
> > identifier stored on each record so Keycloak can do the filtering down to
> > the 100 correct records
> >
> b) Receive a push claim, for each of the 1mil transaction records,
> > indicating who the "creator" is, so it may be matched against the current
> > user and thus filter down to the 100 correct records
> >
> > c) During evaluation, the policy engine can call out to a service
> > somewhere to get the primary keys of the subset of records this user can
> > see (this may be like a Claim Information Point), then whittle the full
> > list down to just those matching primary keys (kind of like sending an IN
> > list of primary keys in a SQL WHERE clause)
> >
> > d) Something more like the “partial evaluation” that OPA blog and Dmitry
> > has been talking about
> >
> You don't need to create a "creator" attribute. Resources in Keycloak
> always have a owner. It can be the resource server (the application) itself
> or some user in your realm. See
>
> https://www.keycloak.org/docs/latest/authorization_services/index.html#_resource_overview
> .
>
> I just realized that we have another option in Keycloak that might be
> helpful to solve data filtering. I think it is similar to what you linked
> from OPA docs. Some background first about the capability that may help
> with that.
>
> In Keycloak, policies are allowed to push back claims to resource server
> (the application protecting the resources you want to access). Quite
> similar to Advice/Obligation in XACML. The idea is push back additional
> constratins to the application in order to indicate additional checks that
> should be performed by the policy enforcer. As a note, our CIPs do that in
> order to reinforce access to resources based on any claim pushed to
> Keycloak when evaluating permissions.
>
> Let me give you an example. Consider a Transaction resource that you
> created in Keycloak. This is a generic resource representing all your
> transactions. Suppose you have a specific scope that represents an
> operation that lists all user transactions. Let's call this scope
> "transaction:list". This scope is associated with the Transaction resource.
> So you have:
>
> Resource: Transaction
> Scopes: transaction:list
>
> Now, in addition to any other policy that applies to the Transaction
> resource (role, group, whatever) you have a specific permissions that
> govern access to the "transaction:list" scope. This permissions is granted
> by a "List Transaction Policy" as follows:
>
> var permission = $evaluation.getPermission();
> var identity = $evaluation.getContext().getIdentity();
>
> permission.addClaim('data.filter.userId', identity.getId());
>
> $evaluation.grant();
>
> Now, the client application acting on behalf of your user tries to access
> your application at "/api/v1/transaction" using HTTP GET. You know that GET
> method on that endpoint is associated with the "transaction:list" scope, so
> you ask Keycloak for permissions to "Transaction" resources +
> "transaction:list" scope.
>
> As a result, Keycloak will give you a response as follows:
>
> "permissions": [
> {
> "scopes": [
> "album:list"
> ],
> "claims": {
> "data.filter.userId": [
> "e68fa92d-6167-438f-844b-78c7abfc0dd2"
> ]
> },
> "rsid": "d3aaaf68-50cf-4c5c-97b9-99910a7bfb27",
> "rsname": "Transaction Resource"
> }
> ]
>
> In your application you can use the permission granted above, and the
> "data.filter.userId" claim to create a query in your database as follows:
>
> StringBuilder filter = new StringBuilder();
> Map<String, Object> queryParams = new HashMap<String, Object>();
>
> for (Map.Entry<String, Set<String>> entry :
> permission.getClaims().entrySet()) {
>
> if (filter.length() != 0) {
> filter.append(" and ");
> }
>
> String key = entry.getKey();
>
> if (key.startsWith("data.filter")) {
> String left = key.substring(key.lastIndexOf('.') + 1);
> filter.append(left).append(" = :").append(left);
> queryParams.put(left, entry.getValue());
> }
> };
>
> Query query = this.entityManager.createQuery("from Transaction where "
> + filter.toString());
>
> for (Map.Entry<String, Object> entry : queryParams.entrySet()) {
> query.setParameter(entry.getKey(), entry.getValue());
> }
>
> The key points here are:
>
> * You are using a single resource to represent all transactions in your
> system
>
> * You are using a specific policy to protect the "transaction:list"
> operation by pushing back to your application how access should be
> enforced
>
> * Access management is still centralized and you can push back the
> "data.filter" claim with any information you want in order to indicate
> to the application how data must be filtered
>
> * Your policies are using information already available from the
> eluvation context (like user id, user attributes, user roles, groups)
> without being forced to push any claim to the server
>
> In fact, I can use this in one of our quickstarts that is using a
> database and protecting data. So we could introduce something similar
> to this in order to filter recors in addition to protect API
> endpoints.
>
> How that sounds to you ?
>
>
> >
> > General:
> >
> > 2.5) In general, it seems to me the bigger the chunks of extra context
> > provided by application logic to the policy engine, the less detail about
> > the actual constraints being enforced you have controlled and visible in
> > the policy layer… somewhat defeating the purpose of the policy layer.
> Does
> > that sound correct? I could see us offloading a ton of detail to the
> push
> > claims – rather than, say, duplicating more of our business model in
> > keycloak – and then realizing very little of our actual policy permission
> > details are visible or controllable in the policy layer. So I am not
> sure
> > what we are getting at that point.
> >
> > a) An answer might be drawing the line at only role-based
> > access control in the policy layer since that affinity is more easily
> > provided as input (thought that could even be debated)
> >
> > b) Maybe we try to define and draw the line at
> > “resource-based” controls only in the policy layer
> >
> > c) Maybe we make the unit of work for each push claim so
> > granular that truly all of the policy rules that are occurring are
> > basically expressed in the policy layer (thus allowing control,
> flexibility
> > and visibility in one consolidated place)
> >
> >
> >
> > Thanks for your time.
> >
> >
> >
> > Rob Byrd
> >
> > DST
> >
> > Solutions Lead
> >
> > SS&C Technologies Inc. | 1055 Broadway, Kansas City, MO 64105
> >
> > t: (816) 435-7286 *| *m (816) 509-0119
> >
> > *rmbyrd at dstsystems.com <rmbyrd at dstsystems.com>* | *www.ssctech.com
> > <http://www.ssctech.com/>*
> >
> > Follow us: [image: cid:image001.png at 01D412C1.A14C5770]
> > <https://www.linkedin.com/company/ss-c-technologies/> | [image:
> > cid:image002.png at 01D412C1.A14C5770] <https://twitter.com/ssctechnologies>
> |
> > [image: cid:image003.png at 01D412C1.A14C5770]
> > <https://www.facebook.com/ssctechnologies/>
> >
> >
> >
> > *From:* Pedro Igor Silva [mailto:psilva at redhat.com]
> > *Sent:* Thursday, November 8, 2018 2:20 PM
> > *To:* Byrd, Rob M <rmbyrd at dstsystems.com>
> > *Cc:* Dmitry Telegin <dt at acutus.pro>; keycloak-user <
> > keycloak-user at lists.jboss.org>
> > *Subject:* Re: [keycloak-user] Data filtering in SQL
> >
> >
> >
> >
> >
> > On Thu, Nov 8, 2018 at 5:44 PM Byrd, Rob M <rmbyrd at dstsystems.com>
> wrote:
> >
> > Thanks Dmitry and Pedro,
> >
> >
> >
> > Pardon my simple-minded response below, but I am wondering how these
> > specific items would work? Dmitry, yes I agree your GET
> > /projects/<project> and GET /projects scenario is on point for the issue
> –
> > I hope my questions below can further clarify the discussion. Here, I
> will
> > have to make a “go or no-go” decision in about a week. J I would love to
> > take on the challenge of searching for the “holy grail” in this, but atm
> > will need to figure out what Keycloak (or OPA, etc.) can confidently do
> > today.
> >
> >
> >
> > Thanks for the great discussion and continued help!
> >
> >
> >
> > Questions
> >
> > 1) Simple role-based authorization policy seems doable.
> >
> > - Ex: “Only veterinarians are allowed to read pet profiles.”
> >
> >
> >
> > 2) But how to answer once more context is needed, such as one resource’s
> > affinity to another? Literally how does the application figure it out?
> > Like the below example would need a pet-veterinarian mapping resolved
> > somehow, it seems:
> >
> > - “Only the treating veterinarian is allowed to read a pet’s profile.”
> >
> > Just like in OPA, but using a different approach, you can also push
> > information (the input in OPA) to your policies. We call this "pushing
> > claims" [1]. In our policy enforcer we also have the concept of a Claim
> > Information Point [2] (similar concent as a PIP) which you can configure
> to
> > automatically push claims to your policies when checking access for a
> > particular resource. There is also a CIP that allows you to fetch claims
> > from external services.
> >
> >
> >
> > Besides, a resource in Keycloak has attributes, which can be anything you
> > want. So you could, for instance, have a Pet Foo resources in Keycloak
> and
> > update a "veterinarian" attribute associated with it. So you could have a
> > policy that checks if the user making the request is the same defined in
> > the attribute.
> >
> >
> >
> > [1]
> >
> https://www.keycloak.org/docs/latest/authorization_services/index.html#_service_pushing_claims
> >
> > [2]
> >
> https://www.keycloak.org/docs/latest/authorization_services/index.html#_enforcer_claim_information_point
> >
> >
> >
> >
> > -
> >
> >
> >
> > 3) Keycloak has taken an example of “Pet owners can access their own
> pet’s
> > profiles.” and said we can write policies saying that "Only Owner" can
> > access "/api/petservice/pet/{id}". But how does the policy engine figure
> > out who is the owner of /pet/2 vs /pet/3?
> >
> > I can think two options. Like I mentioned before, we are resource-based
> > and resources have an owner. So you can write policies that check if the
> > resource owner is the user making the authorization request. Another
> option
> > is to push claims.
> >
> > 4) Similarly, an OPA blog
> >
> https://blog.openpolicyagent.org/write-policy-in-opa-enforce-policy-in-sql-d9d24db93bf4
> > gives the example where “Only the treating veterinarian is allowed to
> read
> > a pet’s profile, and only when signed in from a device at the pet’s
> > clinic”. Again, it is easy enough to provide the OPA engine the target
> pet
> > and the current device location, but how exactly is it determined who is
> > the treating veterinarian of that pet and what clinic the pet belongs to?
> >
> > 5) In general, the security difficulty is constraining what a user can
> > see/do in a particular feature, so how exactly would a policy engine
> bring
> > back a subset of records that particular user can see (based on their
> > affiliated company, etc.)?
> >
> > 6) Similarly, how exactly would a policy engine bring back all records
> but
> > not the fields a user should not see (such as employee salary field,
> unless
> > the user is a HR VIP)? These last two could be likened to @PostAuth
> > post-filtering in spring security.
> >
> > You can have all those resources protected by Keycloak and make
> > authorization requests to obtain the resources a user has access. We
> > provide a REST API to create resources. And that is the point I tried to
> > make when I said that data security is not really among the use cases we
> > are trying to solve. Although it is possible. Keycloak allows you to
> send a
> > "give me all" permission request. That means returning permissions for
> any
> > resource, managed by Keycloak, that an user can access. But yeah,
> depending
> > on how many resources you have you may end up with a huge response and a
> > bad performance.
> >
> >
> >
> > Another approach is define a single Employee resource with a Salary scope
> > to represent all your employees. So you could enforce access to your real
> > employees and their salary based on the decisions made by the server for
> > this single resource.
> >
> >
> >
> > The decision for one approach or another really depends on how fine
> > grained you want to be, like I mentioned before. Do you need to manage
> > indivudual employees or they all share the same access policies ?
> >
> >
> >
> > See this
> >
> https://github.com/keycloak/keycloak-quickstarts/tree/master/app-authz-rest-employee
> > .
> >
> >
> >
> > Regarding fields (e.g: salary) you could consider it as a scope
> > associated with a resource. In Keycloak you can define permissions for
> > scopes, not only for resources.
> >
> >
> >
> >
> >
> > Rob Byrd
> >
> > DST
> >
> > Solutions Lead
> >
> > SS&C Technologies Inc. | 1055 Broadway, Kansas City, MO 64105
> >
> > t: (816) 435-7286 *| *m (816) 509-0119
> >
> > *rmbyrd at dstsystems.com <rmbyrd at dstsystems.com>* | *www.ssctech.com
> > <http://www.ssctech.com/>*
> >
> > Follow us: [image: cid:image001.png at 01D412C1.A14C5770]
> > <https://www.linkedin.com/company/ss-c-technologies/> | [image:
> > cid:image002.png at 01D412C1.A14C5770] <https://twitter.com/ssctechnologies>
> |
> > [image: cid:image003.png at 01D412C1.A14C5770]
> > <https://www.facebook.com/ssctechnologies/>
> >
> >
> >
> > *From:* Pedro Igor Silva [mailto:psilva at redhat.com]
> > *Sent:* Thursday, November 8, 2018 6:42 AM
> > *To:* Dmitry Telegin <dt at acutus.pro>
> > *Cc:* Byrd, Rob M <rmbyrd at dstsystems.com>; keycloak-user <
> > keycloak-user at lists.jboss.org>
> > *Subject:* Re: [keycloak-user] Data filtering in SQL
> >
> >
> >
> > Hi Dmitry,
> >
> >
> >
> > Agree with you when you mention application vs data security. I also
> agree
> > that Keycloak can also solve data security problems.
> >
> >
> >
> > Privacy is one of the main reasons behind our UMA support a very
> important
> > aspect of data security. In addition to privacy, we also added extensions
> > to UMA and OAuth2 standards to enable applications to use Keycloak as a
> > Policy Decision Point, mainly target for application security.
> >
> >
> >
> > As PDP (and PAP), Keycloak allows you to govern access to protected
> > resources and to obtain authorization decisions as a result of the
> > evaluation of policies associated with these resources. Being based on
> UMA
> > and OAuth2 we support token-based authorization but also access control
> > based on the permissions granted by the server. So, yeah, it should be
> > possible to filter data based on those permissions as well dynamically
> > create WHERE clauses.
> >
> >
> >
> > My main concerns about data security are scalability and manageability,
> > two aspects that are closely related to how much fine-grained you want to
> > be. Like I said, in Keycloak you can protect a set of one or more
> resources
> > as well as scope specific permissions, which can span access decisions
> for
> > one or more resources.
> >
> >
> >
> > We are using data security when you enable permissions to users or
> groups,
> > where results are filtered based on the evaluation of these permissions.
> > Performance wise, evaluation is quite satisfactory, being the main
> > challenges the trade-off between usability vs performance. Recently we
> had
> > important changes to improve the performance of our token endpoint and
> > policy evaluation engine and I think we can perform well when fetching
> > permissions from the server for a set of one or more resources.
> >
> >
> >
> > I'm happy to discuss how we can leverage what we have for data security
> if
> > the community is interested.
> >
> >
> >
> > Regards.
> >
> > Pedro Igor
> >
> >
> >
> > On Wed, Nov 7, 2018 at 8:47 PM Dmitry Telegin <dt at acutus.pro> wrote:
> >
> > Hi Rob,
> >
> > On Tue, 2018-11-06 at 16:28 +0000, Byrd, Rob M wrote:
> > > (Hope this is the correct way to reply - let me know if not)
> > >
> > > Thanks. So my concern is really with the whole idea that an Enterprise
> > Application's security constraints could really be all implemented based
> on
> > url-patterns, is that what you guys are thinking?
> >
> > Cannot speak for Keycloak guys, but will put in my 2¢ as an architect -
> > URL-based (or rather resource-based) authorization covers only one aspect
> > of the application security. Data filtering is equally important, but
> it's
> > just another facet of the problem, and needs to be solved accordingly.
> > Indeed, Keycloak doesn't provide OOTB any means for automatically
> limiting
> > subsets of data shown to the user, as Keycloak has a completely different
> > scope (namely Web SSO/IDM solution).
> >
> > However, you can still use Keycloak as a central warehouse for your
> > security (meta)data, and use it the way you want. Like I said before,
> > nothing stops you from defining some policies in Keycloak, then
> retrieving
> > them and converting to a WHERE clause for your SQL/JPQL/NoSQL query.
> >
> > Speaking of NoSQL - this might be not directly relevant to your problem,
> > but still interesting. A similar problem has surfaced in the discussion
> > following my talk on Apache Sling + Keycloak [1] earlier this year; the
> > central point was: "okay, we can have Keycloak path-based authorization
> in
> > Sling, but how do we limit the content visible to the user?"
> > That time we came up with some sort of hybrid solution, like path-based
> > security + JCR ACLs and/or application-level rules; but now I think this
> > might be something similar, like generating JCR's equivalent to the WHERE
> > clause based on Keycloak policy definition.
> >
> > Just to make sure I understand the case, let's imagine:
> > - there are users and groups (live in Keycloak);
> > - there are, say, "projects" (live in business tier + DB);
> > - there is a policy in Keycloak saying "projects should be accessible
> only
> > to the members of the respective groups";
> > - based on that:
> > - GET /projects/<project> should return 200 + representation if the user
> > is a member of the group, 403 otherwise;
> > - GET /projects should return the list of projects the current user has
> > access to.
> >
> > Is this correct?
> >
> > [1]
> >
> https://adapt.to/2018/en/schedule/modern-authentication-in-sling-with-openid-connect-and-keycloak.html
> >
> > Cheers,
> > Dmitry Telegin
> > CTO, Acutus s.r.o.
> > Keycloak Consulting and Training
> >
> > Pod lipami street 339/52, 130 00 Prague 3, Czech Republic
> > +42 (022) 888-30-71
> > E-mail: info at acutus.pro
> >
> > >
> > > For example, mostly a user can visit most features (urls) in an
> > application, but it is the subset of things they can see/do within the
> > feature that is the crux of the security issue - and it does not seem
> > feasible to architect urls in such a way that they can be used as the key
> > to security. Thoughts?
> > >
> > > Thanks!
> > >
> > > Rob Byrd
> > > DST
> > > Solutions Lead
> > > SS&C Technologies Inc. | 1055 Broadway, Kansas City, MO 64105
> > > t: (816) 435-7286 | m (816) 509-0119
> > > rmbyrd at dstsystems.com | www.ssctech.com
> > > Follow us: | |
> > >
> > > -----Original Message-----
> > > > From: Dmitry Telegin [mailto:dt at acutus.pro]
> > > Sent: Friday, November 2, 2018 12:22 AM
> > > > To: Byrd, Rob M <rmbyrd at dstsystems.com>;
> keycloak-user at lists.jboss.org
> > > Subject: Re: [keycloak-user] Data filtering in SQL
> > >
> > > Hello Rob,
> > >
> > > If I get it right, it's all about generating SQL WHERE clause from
> > Keycloak policies? I think this is doable, as Keycloak has a well-defined
> > object model for authorization policies, and it's easy to obtain policy
> > definitions in JSON format. I think Pedro Igor will tell you more about
> > that.
> > >
> > > You should pay attention to the following:
> > > - there are differences in semantics between OPA and Keycloak policies.
> > For example, Keycloak policies do not operate HTTP methods but rather use
> > more generic notion of scopes;
> > > - not every policy type can be easily converted to a WHERE clause. It
> > should be trivial for User/Group/Role policies, but is virtually
> impossible
> > for Script and Rules, as they are just blackboxes that evaluate to true
> or
> > false. Unless of course your DBMS has a built-in JavaScript engine :)
> > >
> > > Good luck!
> > > Dmitry Telegin
> > > CTO, Acutus s.r.o.
> > > Keycloak Consulting and Training
> > >
> > > Pod lipami street 339/52, 130 00 Prague 3, Czech Republic
> > > +42 (022) 888-30-71
> > > E-mail: info at acutus.pro
> > >
> > > On Thu, 2018-11-01 at 21:39 +0000, Byrd, Rob M wrote:
> > > > I am comparing OPA authorization to Keycloak - how could I enforce
> > Keycloak policy in the SQL closest to the data for good performance,
> > including returning subsets of lists? OPA discusses this at
> >
> https://blog.openpolicyagent.org/write-policy-in-opa-enforce-policy-in-sql-d9d24db93bf4
> > .
> > > >
> > > > Thanks!
> > > >
> > > > Rob Byrd
> > > > DST
> > > > Solutions Lead
> > > > SS&C Technologies Inc. | 1055 Broadway, Kansas City, MO 64105
> > > > t: (816) 435-7286 | m (816) 509-0119
> > > > rmbyrd at dstsystems.com<mailto:rmbyrd at dstsystems.com> |
> > www.ssctech.com<http://www.ssctech.com/>;;
> > > > > > Follow us: [cid:image001.png at 01D412C1.A14C5770] <
> > https://www.linkedin.com/company/ss-c-technologies/> | [
> > cid:image002.png at 01D412C1.A14C5770] <https://twitter.com/ssctechnologies
> > > | [cid:image003.png at 01D412C1.A14C5770] <
> > https://www.facebook.com/ssctechnologies/>
> > > >
> > > >
> > > >
> > > > Please consider the environment before printing this email and any
> > attachments.
> > > >
> > > > This e-mail and any attachments are intended only for the individual
> > or company to which it is addressed and may contain information which is
> > privileged, confidential and prohibited from disclosure or unauthorized
> use
> > under applicable law. If you are not the intended recipient of this
> e-mail,
> > you are hereby notified that any use, dissemination, or copying of this
> > e-mail or the information contained in this e-mail is strictly prohibited
> > by the sender. If you have received this transmission in error, please
> > return the material received to the sender and delete all copies from
> your
> > system.
> > > > _______________________________________________
> > > > keycloak-user mailing list
> > > > keycloak-user at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/keycloak-user
> > >
> > >
> > > Please consider the environment before printing this email and any
> > attachments.
> > >
> > > This e-mail and any attachments are intended only for the individual or
> > company to which it is addressed and may contain information which is
> > privileged, confidential and prohibited from disclosure or unauthorized
> use
> > under applicable law. If you are not the intended recipient of this
> e-mail,
> > you are hereby notified that any use, dissemination, or copying of this
> > e-mail or the information contained in this e-mail is strictly prohibited
> > by the sender. If you have received this transmission in error, please
> > return the material received to the sender and delete all copies from
> your
> > system.
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >
> > ------------------------------
> >
> > Please consider the environment before printing this email and any
> > attachments.
> >
> > This e-mail and any attachments are intended only for the individual or
> > company to which it is addressed and may contain information which is
> > privileged, confidential and prohibited from disclosure or unauthorized
> use
> > under applicable law. If you are not the intended recipient of this
> e-mail,
> > you are hereby notified that any use, dissemination, or copying of this
> > e-mail or the information contained in this e-mail is strictly prohibited
> > by the sender. If you have received this transmission in error, please
> > return the material received to the sender and delete all copies from
> your
> > system.
> >
> > ------------------------------
> > Please consider the environment before printing this email and any
> > attachments.
> >
> > This e-mail and any attachments are intended only for the individual or
> > company to which it is addressed and may contain information which is
> > privileged, confidential and prohibited from disclosure or unauthorized
> use
> > under applicable law. If you are not the intended recipient of this
> e-mail,
> > you are hereby notified that any use, dissemination, or copying of this
> > e-mail or the information contained in this e-mail is strictly prohibited
> > by the sender. If you have received this transmission in error, please
> > return the material received to the sender and delete all copies from
> your
> > system.
> >
> >
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
More information about the keycloak-user
mailing list