social roles
by Bill Burke
Each realm will probably need a set of roles that pertain to social
permissions i.e. : email-request, contacts, etc. We need to compile a
list of them...
We'll then assign scope mappings to registered applications and oauth
clients if social is enabled for the realm.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
7 years, 6 months
Fwd: Re: [security-dev] Federated JDO more than an IDM API?
by Bill Burke
FYI: I posed the "Is PIcketlink JDO?" question.
-------- Original Message --------
Subject: Re: [security-dev] Federated JDO more than an IDM API?
Date: Wed, 31 Jul 2013 15:27:30 -0400 (EDT)
From: Pedro Igor Silva <psilva(a)redhat.com>
To: Bill Burke <bburke(a)redhat.com>
CC: security-dev(a)lists.jboss.org
This is a good perspective. If we consider the support for different
repositories and their mappings, plus the IDM capabilities. But IMO
we're not so generic as JDO and have a more specific scope, where the
mapping config is limited to provide the minimal support to get your
identity data recognized and manageable using these repositories.
Beside that, I think what we're doing with the IDM is not related with
federation, yet.
We're just providing an API from where your different repositories, full
of identity data, can be accessed as a single virtual repository. The
federation part implies you need to link the identity data between
different security domains (eg.: B2B), where in this case you are more
likely to use some standard such as SAML, oAuth or even SCIM (for a
cross-domain identity management). All backed by the IDM API.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: security-dev(a)lists.jboss.org
Sent: Wednesday, July 31, 2013 10:06:18 AM
Subject: [security-dev] Federated JDO more than an IDM API?
Isn't the IDM API turning more into a Federated JDO project than an
actual IDM API? I"ve found at least one JPA/JDO implementation that
supports an LDAP store, but haven't found one yet that does federation.
--
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
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
7 years, 7 months
abstracting out picketlink
by Bill Burke
Don't laugh, I know I said I wasn't going to do this, but I am now.
Abstracting out picketlink will make an easier transition for me to fit
in the new version of Picketlink. Obviously it will also allow us to
dump Picketlink too if it turns out its just not going to scale or they
aren't accepting our pull requests. Hopefully we won't have to do that
though.
So merge from master often as I'll be committing as I go.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
7 years, 7 months
Admin UI
by Stian Thorgersen
If everyone could have a look at http://wildfly-stianst.rhcloud.com/keycloak-server/ui/index.html and tell me what they think that would be great. In my mind it's what we would use for the first milestone of the project. Probably with a few minor changes, such as adding a field or two.
For the future I would hope that Gabriel produces a nice new look and feel (based on official Red Hat guidelines) as well as improving the usability.
7 years, 7 months
What I need from Hangout today
by Bill Burke
* I'll talk about what I have implemented so far.
* How does social login work? Is it a set of redirects? What
information can we pass social login and have it sent back to us?
* Need to figure out the API so I can refactor the token service so
social login can be implemented.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
7 years, 7 months
Fwd: [security-dev] Keycloak datamodel
by Bill Burke
Picketlink was interested in our datamodel. Here's what I hacked based
on previous Picketlink IDM constraints.
-------- Original Message --------
Subject: [security-dev] Keycloak datamodel
Date: Tue, 30 Jul 2013 08:44:37 -0400
From: Bill Burke <bburke(a)redhat.com>
To: security-dev(a)lists.jboss.org <security-dev(a)lists.jboss.org>
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
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.
* 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
Resource (maps to Tier)
* Roles
* User/RoleMapping
* ScopeRelationship
--
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
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
7 years, 7 months
