Security Hangout Invitation
by Anil Saldhana
The following is a new meeting request:
Subject: Security Hangout
Organizer: "Anil Saldhana" <asaldhan(a)redhat.com>
Location: Google Hangout
Time: Thursday, October 25, 2012, 8:15:00 AM - 9:15:00 AM GMT -06:00
US/Canada Central
Invitees: anil.saldhana(a)redhat.com
*~*~*~*~*~*~*~*~*~*
Lets meet to discuss Security.
11 years, 6 months
Hangout on Wednesday or Thursday
by Anil Saldhana
Hi All,
I am wondering if we can have a hangout on wed or thu towards evening
(to accommodate Shane)? This is mainly to discuss where we are.
Regards,
Anil
11 years, 6 months
PicketLink Version and "Core" Module name
by Anil Saldhana
a) I am presuming we have agreement that the PicketLink version for the
consolidated workspace should be v3.x
b) Regarding the module name "core" that most of us want renamed to "cdi".
I do not see issues with it called "core" as long as PL 2.x federation
users on non-ee environments upgrading to PL3 do not have a requirement
to have CDI/Weld jars. Ideally we cannot force users to require Weld
jars to run SAML on tomcat, for example.
11 years, 6 months
Credential validation and storage
by Shane Bryzak
Hi guys,
I'd like to simplify the Identity Management API a bit where credentials
are concerned. At the moment we have the following methods defined by
the IdentityManager interface:
// Password Management
boolean validatePassword(User user, String password);
void updatePassword(User user, String password);
void setPasswordEncoder(PasswordEncoder encoder);
// Certificate Management
boolean validateCertificate(User user, X509Certificate certificate);
boolean updateCertificate(User user, X509Certificate certificate);
Furthermore, in IdentityStore we have these methods which are
essentially identical:
boolean validatePassword(User user, String password);
void updatePassword(User user, String password);
// Certificate Management
boolean validateCertificate(User user, X509Certificate certificate);
boolean updateCertificate(User user, X509Certificate certificate);
What I'd like to do is make this a little more abstract (and more future
proof) by replacing these methods (in both interfaces) with the
following two methods:
boolean validateCredential(User user, Credential credential);
void updateCredential(User user, Credential credential);
Once the method invocation hits the IdentityStore implementation, we
have a choice as to what we want to do here. I think the best option is
to go with a credential encoding API based on the work that Pedro has
already done (see [1] and [2]). My only suggestion would be to:
a) make it a little more generic (we should use a factory object or
something to provide the IdentityStore implementation with the correct
encoder based on the type of credential)
b) provide the encoder implementation with an invocation context
containing a reference back to the calling IdentityStore to allow access
to its internal methods and/or other state, and
c) provide pluggable access to the encoding process, to allow the
developer to provide custom behaviour for the encoding.
Does anyone have any suggestions or thoughts on this?
Shane
[1]
https://github.com/picketlink/picketlink/blob/master/idm/api/src/main/jav...
[2]
https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/ja...
11 years, 6 months
IDM security model - Human vs Non human users
by Shane Bryzak
Bolek and I were discussing $SUBJECT quite some time ago, and we came to
the conclusion that it would be nice to be able to differentiate between
users that are human, and users that are not. I hope that everyone can
appreciate why this might be important for today's interconnected web.
Anyway, I've been contemplating an elegant way to implement this, and
I'd like to run the following idea past you guys.
Currently, the User interface extends IdentityType, like so:
public interface User extends IdentityType
This interface declares mostly human-specific methods (besides getId()
and possibly get/setEmail()):
String getId();
String getFirstName();
void setFirstName(String firstName);
String getLastName();
void setLastName(String lastName);
String getFullName();
String getEmail();
void setEmail(String email);
What I would like to do, is introduce another interface in between User
and IdentityType, called Agent:
public interface Agent extends IdentityType {
String getId();
String getEmail();
void setEmail(String email);
}
The User interface would then extend this and provide the human-specific
methods:
public interface User extends Agent {
String getFirstName();
void setFirstName(String firstName);
String getLastName();
void setLastName(String lastName);
String getFullName();
}
This change would require some modifications to the IdentityManager
interface. We currently have the following user-related methods:
User createUser(String name);
User createUser(User user);
void removeUser(User user);
void removeUser(String name);
User getUser(String name);
Collection<User> getAllUsers();
UserQuery createUserQuery();
(as a side note, we will probably remove some of these methods for
simplicity sake)
I see two choices here; 1) we can either leave these methods as-is and
add another set of methods for Agents (createAgent(), removeAgent(),
etc), or 2) we can update the methods to work with Agents instead of
Users (as a User is an Agent anyway). I am kind of leaning towards
option 1) because it keeps it simple and intuitive for developers, but I
also like option 2) because it reduces the overall number of methods.
That basically sums up the idea. This will give us support for
non-human connections to an application, and provides some
future-proofing should any similar requirements come along later. I'd be
interested in hearing any feedback on this, for the overall idea in
general and specifically for the IdentityManager changes.
Shane
11 years, 6 months
Meaningful relationships
by Shane Bryzak
No, not that kind. I'm currently reviewing the database schema for the
identity management module - in the previous version of PicketLink we
had quite a good design [1] that was a little abstract, but met all the
requirements well. Here's a summary of the key tables:
IdentityObject - this table would contain both User and Group records
IdentityObjectRelationship - models the relationship between User and
Group, i.e. Group memberships
IdentityObjectRelationshipName - this table is a special one that
contained the names for "named relationships". A named relationship can
effectively be thought of as a Role, (and was also modelled in the
IdentityObjectRelationship table) for example "John" (User) is a
"Manager" (Role, the "named" bit of the relationship) in "Head Office"
(Group) - see [2] for more details.
With the introduction of application roles we need to jig this design a
little bit. I was thinking of keeping IdentityObject essentially the
same, with the exception that it would also be used to contain Roles, as
well as Users and Groups. Instead of the IdentityObjectRelationship
table though, I propose we go with the following slightly less abstract
design:
IdentityMembership
-------------------------
MEMBER
GROUP
ROLE
This basically allows us to make any IdentityType (User, Group or Role)
a member of a Group or Role, or both. Here's a few scenarios:
1. John is a part of the accounting group.
IdentityMembership
-------------------------
MEMBER = John (User)
GROUP = accounting
ROLE = null
2. The Manager group is a subgroup of the Employee group.
IdentityMembership
-------------------------
MEMBER = Manager (Group)
GROUP = Employee
ROLE = null
3. Kevin is an administrator for the Manager group
IdentityMembership
-------------------------
MEMBER = Kevin (User)
GROUP = Manager
ROLE = Admin
4. Kelly is a superuser (which is an application role)
IdentityMembership
-------------------------
MEMBER = Kelly (User)
GROUP = null
ROLE = Superuser
With the above examples in mind, this now leads into the "meaningful
relationships" theme - can anyone think of any other meaningful security
relationships that cannot be modelled with this design? I'm not really
looking to make the design "future proof" as such, but I would like to
ensure we cover all currently known scenarios / use cases. Comments and
feedback welcome of course.
[1]
http://anonsvn.jboss.org/repos/picketlink/idm/downloads/docs/1.0.0.GA/Ref...
[2]
http://anonsvn.jboss.org/repos/picketlink/idm/downloads/docs/1.0.0.GA/Ref...
11 years, 6 months
OAuth 2.0 RFCs Completed
by Anil Saldhana
-------- Original Message --------
Subject: [jose] FW: OAuth 2.0 RFCs Completed
Date: Fri, 12 Oct 2012 23:38:35 +0000
From: Mike Jones <Michael.Jones(a)microsoft.com>
To: jose(a)ietf.org <jose(a)ietf.org>
FYI
*From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf
Of *Mike Jones
*Sent:* Friday, October 12, 2012 4:34 PM
*To:* oauth(a)ietf.org
*Subject:* [OAUTH-WG] OAuth 2.0 RFCs Completed
The OAuth 2.0 Core and Bearer specifications are now RFC 6749
<http://www.rfc-editor.org/rfc/rfc6749.txt> and RFC 6750
<http://www.rfc-editor.org/rfc/rfc6750.txt>. Thanks to all of you who
brought us to this important milestone!
I wrote about this at http://self-issued.info/?p=870 and Dick wrote
about it at http://dickhardt.org/2012/10/oauth-2-0/.
Now, on to approving the next set of related standards!
Thanks all!
-- Mike
11 years, 6 months
RFC 6749 on The OAuth 2.0 Authorization Framework
by Anil Saldhana
-------- Original Message --------
Subject: [OAUTH-WG] RFC 6749 on The OAuth 2.0 Authorization Framework
Date: Fri, 12 Oct 2012 15:42:52 -0700 (PDT)
From: rfc-editor(a)rfc-editor.org
To: ietf-announce(a)ietf.org, rfc-dist(a)rfc-editor.org
CC: oauth(a)ietf.org, rfc-editor(a)rfc-editor.org
A new Request for Comments is now available in online RFC libraries.
RFC 6749
Title: The OAuth 2.0 Authorization Framework
Author: D. Hardt, Ed.
Status: Standards Track
Stream: IETF
Date: October 2012
Mailbox: dick.hardt(a)gmail.com
Pages: 76
Characters: 163498
Obsoletes: RFC5849
I-D Tag: draft-ietf-oauth-v2-31.txt
URL: http://www.rfc-editor.org/rfc/rfc6749.txt
The OAuth 2.0 authorization framework enables a third-party
application to obtain limited access to an HTTP service, either on
behalf of a resource owner by orchestrating an approval interaction
between the resource owner and the HTTP service, or by allowing the
third-party application to obtain access on its own behalf. This
specification replaces and obsoletes the OAuth 1.0 protocol described
in RFC 5849. [STANDARDS-TRACK]
This document is a product of the Web Authorization Protocol Working Group of the IETF.
This is now a Proposed Standard Protocol.
STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements. Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
http://www.ietf.org/mailman/listinfo/ietf-announce
http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.
Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor(a)rfc-editor.org. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
The RFC Editor Team
Association Management Solutions, LLC
_______________________________________________
OAuth mailing list
OAuth(a)ietf.org
https://www.ietf.org/mailman/listinfo/oauth
11 years, 6 months
PicketLink workspace proposal
by Anil Saldhana
Hi all,
here is what Shane and I have been discussing in the last 10 days
that we can come to an agreement in this thread. Please provide your
feedback and insights as we move forward with the PicketLink main workspace.
Proposal:
PicketLink main workspace will have the following modules:
a) core : will contain the CDI based security code that Shane has been
driving.
b) idm: will contain the idm api and impl submodules. This is low
dependency JavaSE library for Identity Management functionality (CRUD of
users/roles/groups). This module is ultra critical to all projects.
c) federation: will contain the core SAML (and maybe WS-Trust) code
without any EE container dependencies. Mainly parsing, writing and model
code.
d) social: will contain social login code that allows signin using
facebook, google/openid, twitter.
Versioning:
Last major release of PL has been with 2.1.5
(https://docs.jboss.org/author/display/PLINK/v2.1.5.Final)
So definitely we can release above with 3.x
Since we may need some container binding code with AS, Tomcat etc, we
have two possibilities:
a) Create another workspace in PicketLink github organization for the
container binding. (My preference)
b) Create a separate github organization that will host all the
container bindings, integration testing workspaces etc. We can call it
picketlinkbindings.
Regards,
Anil
11 years, 6 months