[security-dev] PicketLink IDM Relationships and SASL Authorizations

Pedro Igor Silva psilva at redhat.com
Thu Jun 20 15:15:23 EDT 2013


Hi Darran,

   I wrote a simple test case to try to satisfy your objectives.

       https://gist.github.com/pedroigor/5825698

   We can also use custom attributes if you need some kind of metadata for each relationship instance.   

----- Original Message -----
From: "Darran Lofthouse" <darran.lofthouse at jboss.com>
To: security-dev at lists.jboss.org
Sent: Thursday, June 20, 2013 12:27:08 PM
Subject: [security-dev] PicketLink IDM Relationships and SASL Authorizations

Within SASL there is a capability where during the authentication phase 
the agent being authenticated can request that subsequently they want 
the authorization privileged of another agent.

The loading the identity of the agent being requested is fine but at the 
moment I am looking within PicketLink IDM at how this one agent being 
able to run as another agent can be modeled.

I can see using a custom relationship how it should be fairly easy to 
model a 1:1 mapping of users that an 'impersonate' each other but I have 
a few additional scenarios that could also be needed so wanted to look 
for ideas on how to support all of these simultaneously.

  - A single agent can impersonate a single agent.
  - A single agent can impersonate any user that is a member of a 
specified group.
  - A member of a specific group can impersonate a single agent.
  - A member of one group can impersonate an agent of another (or same) 
group.

As mentioned in IRC over the last couple of days having some form of 
permissions check API in the IDM for the non AS processes feels like it 
would fit this really well - however at the moment I can perform this 
check outside of any permissions API so just looking for ideas how it 
could be achieved.

Regards,
Darran Lofthouse.


_______________________________________________
security-dev mailing list
security-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev


More information about the security-dev mailing list