| RE: [alf-req] Do roles play a role in the ALF runtime? |
Aldon has looked at roles a little differently than Shaw. Attached is a document that is intended for discussion purposes, that take the opposite viewpoint. Patrick Flanigan -----Original Message----- From: alf-req-bounces@xxxxxxxxxxx [mailto:alf-req-bounces@xxxxxxxxxxx]On Behalf Of Kelly Shaw Sent: Thursday, September 01, 2005 8:40 AM To: alf-req@xxxxxxxxxxx Subject: [alf-req] Do roles play a role in the ALF runtime? This is a multi-part message in MIME format. _=_NextPart_001_01C5AF03.457D7436 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 We left off yesterday's discussions about roles with no clear understanding of what role roles play within ALF. I would like to offer up the following to start off the debate: =20 Thesis: Roles play no official role in the ALF runtime. =20 Why? =20 First, we already decided that ALF would not provide any user management except through an SPI. Without users, how do we assign roles? Where do we manage roles? How do we use roles? =20 Second, it is unlikely that tool vendors will delegate security and permissions checking to ALF. Thus ALF roles, if they exist, can be descriptive, but not prescriptive. If this is the case, then ALF roles are an unnecessary complexity within ALF and should be shaved away, at least for the first release. =20 I would like to propose that we delegate role administration to the same SPI that will allow central user authentication. The SPI plug-in can include role information associated with a user's credentials if it is so implemented, and the tools within a service flow can make use of that role information if they are so configured, but officially, roles play no part in the ALF runtime. Note that WS-Security supports this usage. =20 That said, we do need some sort of permissions checking for the ALF administrator, else anyone would be able to publish a service flow. We could delegate administrative permission checking to another SPI, and provide simple userid/password checking in the example implementation. Then ALF would be completely out of the userid/role/permission/authorization business. At least for the first release. =20 Please, everyone, let's get arguing! =20 shaw =20 Kelly Shaw Sr. Product Marketing Manager Serena Software 719-457-8811 ********************************************************************** This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = Any unauthorized review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-ma= il and destroy all copies of the original message. ------_=_NextPart_001_01C5AF03.457D7436 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.2800.1515" name=3DGENERATOR></HEAD> <BODY> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D664332614-01092005>All,</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D664332614-01092005></SPAN></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D664332614-01092005>We left o= ff=20 yesterday's discussions about roles with no clear understanding of what rol= e=20 roles play within ALF. I would like to offer up the following to start off = the=20 debate:</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D664332614-01092005></SPAN></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D664332614-01092005><STRONG>T= hesis:=20 Roles play no official role in the ALF runtime.</STRONG></SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D664332614-01092005></SPAN></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D664332614-01092005>Why?</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D664332614-01092005></SPAN></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D664332614-01092005>First, we= already=20 decided that ALF would not provide any user management except through an SP= I.=20 Without users, how do we assign roles? Where do we manage roles? How do we = use=20 roles?</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D664332614-01092005></SPAN></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D664332614-01092005>Second, i= t is=20 unlikely that tool vendors will delegate security and permissions checking = to=20 ALF. Thus ALF roles, if they exist, can be descriptive, but not prescriptiv= e. If=20 this is the case, then ALF roles are an unnecessary complexity within ALF a= nd=20 should be shaved away, at least for the first release.</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D664332614-01092005></SPAN></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D664332614-01092005>I would l= ike to=20 propose that we delegate role administration to the same SPI that will allo= w=20 central user authentication. The SPI plug-in can include role information= =20 associated with a user's credentials if it is so implemented, and the tools= =20 within a service flow can make use of that role information if they are so= =20 configured, but officially, roles play no part in the ALF runtime. Note tha= t=20 WS-Security supports this usage.</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D664332614-01092005></SPAN></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D664332614-01092005>That said= , we do=20 need some sort of permissions checking for the ALF administrator, else anyo= ne=20 would be able to publish a service flow. We could delegate administrative= =20 permission checking to another SPI, and provide simple userid/password chec= king=20 in the example implementation. Then ALF would be completely out of the=20 userid/role/permission/authorization business. At least for the first=20 release.</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D664332614-01092005></SPAN></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D664332614-01092005>Please, e= veryone,=20 let's get arguing!</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D664332614-01092005></SPAN></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D664332614-01092005>shaw</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV align=3Dleft><FONT face=3DArial size=3D2>Kelly Shaw</FONT></DIV> <DIV align=3Dleft><FONT face=3DArial size=3D2>Sr. Product Marketing=20 Manager</FONT></DIV> <DIV align=3Dleft><FONT face=3DArial size=3D2>Serena Software</FONT></DIV> <DIV align=3Dleft><FONT face=3DArial size=3D2>719-457-8811</FONT></DIV> <P STYLE=3D"margin-top: 0pt;margin-bottom: 0pt;"><SPAN STYLE=3D"FONT-FAMILY= :'Arial';FONT-SIZE:8pt;">**************************************************= ******************** </SPAN> </P> <P STYLE=3D"margin-top: 0pt;margin-bottom: 0pt;"><SPAN STYLE=3D"FONT-FAMILY= :'Arial';FONT-SIZE:8pt;">This email and any files transmitted with it are c= onfidential and intended solely for the use of the individual or entity to = whom they are addressed. Any unauthorized review, use, disclosure or distri= bution is prohibited. If you are not the intended recipient, please contact= the sender by reply e-mail and destroy all copies of the original message.= </SPAN> </P></BODY></HTML> ------_=_NextPart_001_01C5AF03.457D7436--
Attachment:
ALF Roles Viewpoint.pdf
Description: ALF Roles Viewpoint.pdf