Re: [security-dev] Keycloak datamodel
Some questions:
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: security-dev(a)lists.jboss.org
Sent: Tuesday, July 30, 2013 9:44:37 AM
Subject: [security-dev] Keycloak datamodel
Keycloak is a SaaS in which people can register to create their own realms.
Default Realm:
User
Roles: REALM_CREATOR
Custom RealmAdminRelationship: Attribute: realmId, Attribute: User.
RealmId points to a realm a User has created
You need to know the owner of a specific partition. Why you need a relationship for that ?
Can't you just use the partition's ad-hoc attributes to store such information ?
As you requested, we're now supporting ad-hoc attributes for partitions. So you can
just set the userId as an attribute.
SSO Realms:
* A bunch of attributes for the Realm like private/public key stored in
an Agent
* Users
* Roles
* User/RoleMapping
* Custom RequiredCredentialRelationship. Defines the credential types
required by the realm.
Maybe we can also use ad-hoc attributes here. Where a specific partition attribute can
have a value with all required credentials. A SecurityPolicy class can fit here, where you
can define all policies for a given partition.
* Custom ScopeRelationship. Scope is the same as role mapping, but
this
defines an OAuth grant thing. It is the roles a user is allowed to
request permissions for. It is an Attribute of an Agent and a Role.
* Custom ResourceRelationship. A resource is an application that is
managed by the realm. This has Attribute Agent pointing to the Agent of
the realm, various attributes of the resource, and also a String value
pointing to the Tier. I couldn't figure out how to have a hard
relationship to a Tier
Applications can now be mapped as IdentityTypes. It seems that you're creating a
relationship to tell that an user is authorized to a specific resource/application. Where
this relationship needs some specific information about this relation.
You can write your ResourceRelationship as a simple relationship with a reference for the
User and the Application types (both subtypes of IdentityType).
Resource (maps to Tier)
* Roles
* User/RoleMapping
* ScopeRelationship
You're not more tied to the Realm/Tier concept. You can now specify which types are
supported by your own custom partition.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
security-dev mailing list
security-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev