[security-dev] REST API for user provisioning

[Pedro Igor Silva]

----- Original Message -----
> From: "Shane Bryzak" <sbryzak at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: security-dev at lists.jboss.org
> Sent: Monday, March 11, 2013 5:36:48 PM
> Subject: Re: [security-dev] REST API for user provisioning
> 
> 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?

No special advantage. Just wanted to show the idea.

> 
> 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);

Works too, in a typed manner. My idea was more generic and, of course, weakly-typed.

> 
> >
> > 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
> 
>