[security-dev] REST API for user provisioning

Shane Bryzak sbryzak at redhat.com
Mon Mar 11 16:36:48 EDT 2013


On 11/03/13 23:00, Pedro Igor Silva wrote:
> Maybe we can review the Attribute API and have something like that:
>
> User user = // create user
>
> user.setAttribute(Attribute.create("profileUrl", "http://company/users/profile?id=121")); // the same as new Attribute("",""), just a helper method
>
> Attribute addresses = Attribute
>
>      .create("addresses") // parent, no value defined
>
>          .add("address1") // child of "addresses" and also a parent
>              .add("postalCode", "123")
>              .add("streetAddress", "123")
>              .add("multivalued", "1","2") // multi-valued attribute for "address1"
>
>          .add("address2")
>              .add("postalCode", "456")
>              .add("streetAddress", "456")
>
> user.setAttribute(addresses);

-1 on the static create() method, what advantage does it provide over 
just using the constructor?

For this use case I think I would prefer to create a Serializable 
Address class rather than try to persist an address value as a 
collection of weakly-typed values.  In fact, I think we should be 
providing a package that contains a bunch of commonly useful Attribute 
value classes; address, phone number, SSN, e-mail etc. Then all we need 
to do is this:

Collection<Address> values = new ArrayList<Address>();
Address addr = new Address();
addr.setStreetNumber("123");
addr.setStreetName("Main");
// etc
values.add(addr);

Attribute addresses = new Attribute("addresses", values);

>
> Another thing we can review is the getEmail method on the User interface. Maybe we should support a String array to allow 1+ emails for users.

It is important to maintain a primary e-mail address for the user, for 
additional e-mail addresses they can be stored as attributes.

>
> Regards.
> Pedro Igor
>
> ----- Original Message -----
> From: "Shane Bryzak" <sbryzak at redhat.com>
> To: security-dev at lists.jboss.org
> Sent: Friday, March 8, 2013 7:58:31 PM
> Subject: Re: [security-dev] REST API for user provisioning
>
> Would we be targeting SCIM 1.1 or 2.0? Also, it looks like we can
> already support most of this already with our identity model, although
> for complex types it might be a little bit of a challenge.  I guess one
> possibility though is to just make the Attribute value an array of
> Attributes itself.
>
> On 09/03/13 06:53, Anil Saldhana wrote:
>> Hi All,
>>      now that we have an excellent IDM subsystem as part of PicketLink3,
>> we need to next look at incorporating SCIM
>> (http://www.simplecloud.info/), a set of standards surrounding REST API
>> for Cloud Provisioning. SCIM is part of the IETF.
>>
>> Probably in the PicketLink 3.1+ timeframe.
>>
>> Regards,
>> Anil
>>
>> _______________________________________________
>> security-dev mailing list
>> security-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/security-dev
> _______________________________________________
> 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