Re: [Architecture] [IAM] Passing parameters from authentication script to Authenticators
Hi Pulasthi,
On Mon, Jun 11, 2018 at 11:36 AM Pulasthi Mahawithana
wrote:
> Hi Senthalan,
>
> On Mon, Jun 11, 2018 at 11:10 AM Senthalan Kanagalingam <
> sentha...@wso2.com> wrote:
>
>> Hi all,
>>
>> I am working on the $subject. The purpose of this implementation is to
>> have application-specific configurations for authenticators. Currently, we
>> can static configurations for the authenticators in the
>> application-authentication.xml file.
>>
>> In the script, we can set the parameters as follow, If we want to pass
>> the foo to the authenticator,
>>
>> context.foo = "xyz";
>>
>
>
> Shall we change this to following to avoid any conflicts with existing
> context objects?
>
> context.parameter.foo = "xyz";
> and/or
> context.parameter['foo'] = "xyz";
>
+ 1. I have implemented with the suggestions.
>
>>
>> We can get back the value in the authenticators( executed after this
>> definition) by calling context.getScriptParameter("foo")
>>
>> I have developed a POC for this. I have created a new map in the
>> "AuthenticationContext" to save these parameters.
>>
>> Please share your thoughts about this implementation.
>>
>> thanks,
>> Senthalan.
>>
>>
>> *Senthalan Kanagalingam*
>> *Software Engineer - WSO2 Inc.*
>> *Mobile : +94 (0) 77 18 77 466*
>>
>>
>
>
> --
> *Pulasthi Mahawithana*
> Associate Technical Lead
> WSO2 Inc., http://wso2.com/
> Mobile: +94-71-5179022
> Blog: https://medium.com/@pulasthi7/
>
>
>
--
*Senthalan Kanagalingam*
*Software Engineer - WSO2 Inc.*
*Mobile : +94 (0) 77 18 77 466*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Adding custom attributes to Applications in API Store
Its more of a convention. Since our C4 code is tenant aware, we have a convention to put the tenant id in all the tables so that we can use it for things outside application logic. Such as tenant data removal/cleanup, audits, etc. On Mon, Jun 11, 2018 at 2:15 PM, Vithursa Mahendrarajah wrote: > Hi Godwin, > > Sorry, I misunderstood your previous mail. Currently we don't have a > specific need to use tenant_id from AM_APPLICATION_ATTRIBUTES. We have > added it for future references. > > Thanks, > > On Mon, Jun 11, 2018 at 1:28 PM, Godwin Amila Shrimal > wrote: > >> Hi Vithursa, >> >> What I asked is do we really need to keep tenant_id in >> AM_APPLICATION_ATTRIBUTES table since we already have tenancy in >> Application level ? I guess Application to application attribute has an one >> to many relationship. >> >> Thanks >> Godwin >> >> On Mon, Jun 11, 2018, 6:43 AM Vithursa Mahendrarajah >> wrote: >> >>> Hi Godwin, >>> >>> Yes, Tenant-awareness is incorporated in this feature and tenant_id is >>> stored against each attribute (in AM_APPLICATION_ATTRIBUTES). >>> >>> Thanks, >>> >>> On Mon, Jun 11, 2018 at 10:54 AM, Godwin Amila Shrimal >>> wrote: >>> Hi Vithursa/Nuwan, Sorry for giving my feedback at this moment. Do we have to especially think of tenant awareness for the application attributes and add tennat_id to AM_APPLICATION_ATTRIBUTES table? Our Application is already tenant aware. right? Correct me if I am wrong. Thanks Godwin On Tue, May 1, 2018 at 7:03 AM Vithursa Mahendrarajah < vithu...@wso2.com> wrote: > Hi, > > +1 for making this feature tenant aware. I will accommodate it into > the design. > > As discussed with Nuwan, the table AM_APPLICATION_ATTRIBUTES will be > modified to have an additional column to store tenant_id. > > Thanks & Regards, > > > On Sat, Apr 28, 2018 at 6:55 PM, Nuwan Dias wrote: > >> One more thought that came to mind is that we have to make this >> feature tenant aware. In the sense that each tenant should be able to >> decide its own attributes. Let’s change the design to accommodate that. >> >> On Wed, Apr 25, 2018 at 9:07 PM Vithursa Mahendrarajah < >> vithu...@wso2.com> wrote: >> >>> Hi, >>> >>> I will remove IS_REQUIRE column from AM_APPLICATION_ATTRIBUTES. We >>> can specify in UI as *required* by reading values from xml file. >>> >>> Thanks & Regards, >>> >>> >>> On Wed, Apr 25, 2018 at 1:05 PM, Nuwan Dias wrote: >>> On Wed, Apr 25, 2018 at 12:56 PM, Vithursa Mahendrarajah < vithu...@wso2.com> wrote: > Hi all, > > Please find updated user story in [1]. (Also .pdf is attached). > > As discussed with Nuwan, Following implementation flow is planned > to store custom attributes against an Application. > > 1. In the first step, user needs to configure keys of attributes > in api-manager.xml. Attributes may need to be differentiated as > *required* and *optional*. User should not be able to create an > Application without attributes that marked as *required*. > > For instance, if the required keys were *External Reference Id* > and *Billing Tier *where *External Reference Id* is a mandatory > key, user can configure as, > > > > External Reference > Id > Billing Tier > > > > 2. Next, when creating Application, user can specify values via > UI. Mock UI looks as, > > > > 3. A new table, names as AM_APPLICATION_ATTRIBUTES is created with > 4 columns. Such as, > 1. APPLICATION_ID > 2. ATTRIBUTE_KEY > 3. ATTRIBUTE_VALUE > 4. IS_REQUIRED > Each attribute key, value pairs and boolean indicates whether it > is a mandatory attribute or not, will be stored along with > Application Id. > I don't think we need to store the 'required' field in the database since it is mentioned in the configuration. > > Fetched attributes are committed into AM_APPLICATION_ATTRIBUTES. > Following DB schema will be added to the current API Manager database. > > > Feedback and suggestions are highly appreciated. > > [1] https://docs.google.com/document/d/18OMI3sjHETOcKfQ5fldm4Inf > 4gsU1TxDrhfs2l9GfhI/edit?usp=sharing > > Thanks & Regards, > > > > On Fri, Apr 20, 2018 at 9:41 AM, Vithursa Mahendrarajah < > vithu...@wso2.com> wrote: > >> Hi all, >> @Youcef, >> Thanks for the use case, you have provided. We will try to >>
Re: [Architecture] Adding custom attributes to Applications in API Store
Hi Godwin, Sorry, I misunderstood your previous mail. Currently we don't have a specific need to use tenant_id from AM_APPLICATION_ATTRIBUTES. We have added it for future references. Thanks, On Mon, Jun 11, 2018 at 1:28 PM, Godwin Amila Shrimal wrote: > Hi Vithursa, > > What I asked is do we really need to keep tenant_id in > AM_APPLICATION_ATTRIBUTES table since we already have tenancy in > Application level ? I guess Application to application attribute has an one > to many relationship. > > Thanks > Godwin > > On Mon, Jun 11, 2018, 6:43 AM Vithursa Mahendrarajah > wrote: > >> Hi Godwin, >> >> Yes, Tenant-awareness is incorporated in this feature and tenant_id is >> stored against each attribute (in AM_APPLICATION_ATTRIBUTES). >> >> Thanks, >> >> On Mon, Jun 11, 2018 at 10:54 AM, Godwin Amila Shrimal >> wrote: >> >>> Hi Vithursa/Nuwan, >>> >>> Sorry for giving my feedback at this moment. Do we have to especially >>> think of tenant awareness for the application attributes and add tennat_id >>> to AM_APPLICATION_ATTRIBUTES table? Our Application is already tenant >>> aware. right? Correct me if I am wrong. >>> >>> Thanks >>> Godwin >>> >>> On Tue, May 1, 2018 at 7:03 AM Vithursa Mahendrarajah >>> wrote: >>> Hi, +1 for making this feature tenant aware. I will accommodate it into the design. As discussed with Nuwan, the table AM_APPLICATION_ATTRIBUTES will be modified to have an additional column to store tenant_id. Thanks & Regards, On Sat, Apr 28, 2018 at 6:55 PM, Nuwan Dias wrote: > One more thought that came to mind is that we have to make this > feature tenant aware. In the sense that each tenant should be able to > decide its own attributes. Let’s change the design to accommodate that. > > On Wed, Apr 25, 2018 at 9:07 PM Vithursa Mahendrarajah < > vithu...@wso2.com> wrote: > >> Hi, >> >> I will remove IS_REQUIRE column from AM_APPLICATION_ATTRIBUTES. We >> can specify in UI as *required* by reading values from xml file. >> >> Thanks & Regards, >> >> >> On Wed, Apr 25, 2018 at 1:05 PM, Nuwan Dias wrote: >> >>> >>> >>> On Wed, Apr 25, 2018 at 12:56 PM, Vithursa Mahendrarajah < >>> vithu...@wso2.com> wrote: >>> Hi all, Please find updated user story in [1]. (Also .pdf is attached). As discussed with Nuwan, Following implementation flow is planned to store custom attributes against an Application. 1. In the first step, user needs to configure keys of attributes in api-manager.xml. Attributes may need to be differentiated as *required* and *optional*. User should not be able to create an Application without attributes that marked as *required*. For instance, if the required keys were *External Reference Id* and *Billing Tier *where *External Reference Id* is a mandatory key, user can configure as, External Reference Id Billing Tier 2. Next, when creating Application, user can specify values via UI. Mock UI looks as, 3. A new table, names as AM_APPLICATION_ATTRIBUTES is created with 4 columns. Such as, 1. APPLICATION_ID 2. ATTRIBUTE_KEY 3. ATTRIBUTE_VALUE 4. IS_REQUIRED Each attribute key, value pairs and boolean indicates whether it is a mandatory attribute or not, will be stored along with Application Id. >>> >>> I don't think we need to store the 'required' field in the database >>> since it is mentioned in the configuration. >>> Fetched attributes are committed into AM_APPLICATION_ATTRIBUTES. Following DB schema will be added to the current API Manager database. Feedback and suggestions are highly appreciated. [1] https://docs.google.com/document/d/ 18OMI3sjHETOcKfQ5fldm4Inf4gsU1TxDrhfs2l9GfhI/edit?usp=sharing Thanks & Regards, On Fri, Apr 20, 2018 at 9:41 AM, Vithursa Mahendrarajah < vithu...@wso2.com> wrote: > Hi all, > @Youcef, > Thanks for the use case, you have provided. We will try to > incorporate it and will also share the updated user story. > > @Fazlan, @Ishara, > +1 for your suggestions. I will update the user story and share it. > > @Rajith, > +1 for your suggestion. We could differentiate key values as > *required* and *optional *based on requirements and user can > specify these according to their needs. > > @Nuwan, > Yes, I will work on these. As first step, I will
Re: [Architecture] Adding custom attributes to Applications in API Store
Hi Vithursa, What I asked is do we really need to keep tenant_id in AM_APPLICATION_ATTRIBUTES table since we already have tenancy in Application level ? I guess Application to application attribute has an one to many relationship. Thanks Godwin On Mon, Jun 11, 2018, 6:43 AM Vithursa Mahendrarajah wrote: > Hi Godwin, > > Yes, Tenant-awareness is incorporated in this feature and tenant_id is > stored against each attribute (in AM_APPLICATION_ATTRIBUTES). > > Thanks, > > On Mon, Jun 11, 2018 at 10:54 AM, Godwin Amila Shrimal > wrote: > >> Hi Vithursa/Nuwan, >> >> Sorry for giving my feedback at this moment. Do we have to especially >> think of tenant awareness for the application attributes and add tennat_id >> to AM_APPLICATION_ATTRIBUTES table? Our Application is already tenant >> aware. right? Correct me if I am wrong. >> >> Thanks >> Godwin >> >> On Tue, May 1, 2018 at 7:03 AM Vithursa Mahendrarajah >> wrote: >> >>> Hi, >>> >>> +1 for making this feature tenant aware. I will accommodate it into the >>> design. >>> >>> As discussed with Nuwan, the table AM_APPLICATION_ATTRIBUTES will be >>> modified to have an additional column to store tenant_id. >>> >>> Thanks & Regards, >>> >>> >>> On Sat, Apr 28, 2018 at 6:55 PM, Nuwan Dias wrote: >>> One more thought that came to mind is that we have to make this feature tenant aware. In the sense that each tenant should be able to decide its own attributes. Let’s change the design to accommodate that. On Wed, Apr 25, 2018 at 9:07 PM Vithursa Mahendrarajah < vithu...@wso2.com> wrote: > Hi, > > I will remove IS_REQUIRE column from AM_APPLICATION_ATTRIBUTES. We can > specify in UI as *required* by reading values from xml file. > > Thanks & Regards, > > > On Wed, Apr 25, 2018 at 1:05 PM, Nuwan Dias wrote: > >> >> >> On Wed, Apr 25, 2018 at 12:56 PM, Vithursa Mahendrarajah < >> vithu...@wso2.com> wrote: >> >>> Hi all, >>> >>> Please find updated user story in [1]. (Also .pdf is attached). >>> >>> As discussed with Nuwan, Following implementation flow is planned to >>> store custom attributes against an Application. >>> >>> 1. In the first step, user needs to configure keys of attributes in >>> api-manager.xml. Attributes may need to be differentiated as >>> *required* and *optional*. User should not be able to create an >>> Application without attributes that marked as *required*. >>> >>> For instance, if the required keys were *External Reference Id* and >>> *Billing >>> Tier *where *External Reference Id* is a mandatory key, user can >>> configure as, >>> >>> >>> >>> External Reference >>> Id >>> Billing Tier >>> >>> >>> >>> 2. Next, when creating Application, user can specify values via UI. >>> Mock UI looks as, >>> >>> >>> >>> 3. A new table, names as AM_APPLICATION_ATTRIBUTES is created with 4 >>> columns. Such as, >>> 1. APPLICATION_ID >>> 2. ATTRIBUTE_KEY >>> 3. ATTRIBUTE_VALUE >>> 4. IS_REQUIRED >>> Each attribute key, value pairs and boolean indicates whether it is >>> a mandatory attribute or not, will be stored along with Application Id. >>> >> >> I don't think we need to store the 'required' field in the database >> since it is mentioned in the configuration. >> >>> >>> Fetched attributes are committed into AM_APPLICATION_ATTRIBUTES. >>> Following DB schema will be added to the current API Manager database. >>> >>> >>> Feedback and suggestions are highly appreciated. >>> >>> [1] >>> https://docs.google.com/document/d/18OMI3sjHETOcKfQ5fldm4Inf4gsU1TxDrhfs2l9GfhI/edit?usp=sharing >>> >>> Thanks & Regards, >>> >>> >>> >>> On Fri, Apr 20, 2018 at 9:41 AM, Vithursa Mahendrarajah < >>> vithu...@wso2.com> wrote: >>> Hi all, @Youcef, Thanks for the use case, you have provided. We will try to incorporate it and will also share the updated user story. @Fazlan, @Ishara, +1 for your suggestions. I will update the user story and share it. @Rajith, +1 for your suggestion. We could differentiate key values as *required* and *optional *based on requirements and user can specify these according to their needs. @Nuwan, Yes, I will work on these. As first step, I will work on design and implementation of saving these data against the Application and also will update the user story accordingly. Thanks & Regards, On Thu, Apr 19, 2018 at 11:18 AM, Nuwan Dias wrote: > > > On Thu, Apr 19, 2018 at 11:15 AM, Rajith Roshan > wrote: >
Re: [Architecture] [IS] Filtering authentication options of a step by script
Hi Jerad,
On Sat, Jun 9, 2018 at 10:53 AM Jerad Rutnam wrote:
> Hi Pulasthi,
>
> A minor suggestion on the below configuration part readability.
>
> {authenticationOptions:[
>
> {authenticator:'basic'},
> {idp:'Twitter'},
> {idp:'myIdp', authenticator:'samlsso'}]},
>
> So in the options array first object we have the key "authenticator" with
> the value "basic". And next one just start with the key "idp" with the
> value "Twitter".
> I feel its bit inconsistent WDYT? Can we make it something like below?
>
Sorry for the confusion. As I mentioned in the 'Additional notes' section,
this is a shorthand. If we omit 'idp' it will be considered as the local
IDP, and if we omit authenticator, it will assumed to be the default
authenticator of the given Idp. These were included just to explain those 3
options. By default we'd recommend to use both idp/authenticator
combination as we already do in configuration UI.
>
> {
>
> "authenticationOptions": [
> {
>
> "authenticator": "basic"
>
> },
>
> {
>
> "authenticator": "IDP",
>
> "options": {
>
> "type": "Twitter"
>
> }
>
> },
>
> {
>
> "authenticator": "IDP",
>
> "options": {
>
> "type": "OIDC",
>
> "name": "myIdp",
>
> "method": "samlsso"
>
> }
>
> }
>
> ]
>
> }
>
>
> I'm not sure if the terminology is correct above and correct me if i'm
> wrong. This is just a suggestion by overlook.
>
> Thanks,
>
> --
>
> On Fri, Jun 8, 2018 at 11:13 AM Pulasthi Mahawithana
> wrote:
>
>> Hi,
>>
>> We are planning to provide support for the $subject to cater the
>> requirements where we may need to filter out some options of a step based
>> on some conditions.
>>
>> *Example use case:*
>> We have an authentication step with following options.
>>
>>- Basic authentication
>>- IWA authentication
>>
>> We'll need to show the IWA option only if the user is coming from
>> company's network and from a windows desktop.
>>
>> *Proposed approach:*
>> We'll be changing the 'executeStep' function to accept an optional
>> argument to define pre-conditions for the step. In this precondition
>> section we'll be providing authentication options that need to be made
>> available for the user.
>>
>> executeStep(,,)
>>
>> *Examples:*
>>
>>- Execute step without preconditions or event handlers (existing)
>>
>> executeStep(2);
>>
>>
>>- Execute step without preconditions, but with event
>>handlers (existing)
>>
>> executeStep(2, {
>>
>> onSuccess: function(){},
>> onFail: function(){}});
>>
>>
>>- Execute step with preconditions and event handlers (proposed)
>>
>> executeStep (2,
>>
>> {authenticationOptions:[
>>
>> {authenticator:'basic'},
>> {idp:'Twitter'},
>> {idp:'myIdp',authenticator:'samlsso'}]},
>>
>> {onSuccess: function(){}, onFail: function(){}});
>>
>>
>> In the last example, If we assume that the step 2 is already configured
>> with following options,
>>
>>- Basic authenticator
>>- IWA authenticator
>>- Twitter authenticator (Twitter IDP)
>>- Google authenticator (Google IDP)
>>- OIDC Authenticator (myIdp)
>>
>> The user will only be shown with the basic and twitter options, as the
>> others don't match the authenticationOptions provided in the preconditions.
>>
>> Additional notes:
>>
>>- Authenticators will be specified in the script by the display name
>>instead of the actual authenticator name since it's the display name that
>>is visible to identity admin at the configuration page
>>- If none of the precondition options match any configured options,
>>we'll leave all the options unchanged with a warn log
>>- If 'idp' is omitted in an option it will be assumed as a local
>>authenticator
>>- If 'authenticator' is omitted in an option it will be assumed as
>>the default authenticator of idp
>>- Any precondition steps that are not in the configured options will
>>be ignored.
>>- If 'precondition' parameter is present, 'eventHandler' parameter
>>will be mandatory but can be an empty map.
>>
>> Please let us know of any concerns/suggestions.
>>
>> --
>> *Pulasthi Mahawithana*
>> Associate Technical Lead
>> WSO2 Inc., http://wso2.com/
>> Mobile: +94-71-5179022
>> Blog: https://medium.com/@pulasthi7/
>>
>>
>>
>
>
> --
> *Jerad Rutnam*
> *Senior Software Engineer*
>
> WSO2 Inc.
> lean | enterprise | middleware
> M : +94 77 959 1609 | E : je...@wso2.com | W : www.wso2.com
>
>
>
--
*Pulasthi Mahawithana*
Associate Technical Lead
WSO2 Inc., http://wso2.com/
Mobile: +94-71-5179022
Blog: https://medium.com/@pulasthi7/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [IAM] Passing parameters from authentication script to Authenticators
Hi Senthalan,
On Mon, Jun 11, 2018 at 11:10 AM Senthalan Kanagalingam
wrote:
> Hi all,
>
> I am working on the $subject. The purpose of this implementation is to
> have application-specific configurations for authenticators. Currently, we
> can static configurations for the authenticators in the
> application-authentication.xml file.
>
> In the script, we can set the parameters as follow, If we want to pass the
> foo to the authenticator,
>
> context.foo = "xyz";
>
Shall we change this to following to avoid any conflicts with existing
context objects?
context.parameter.foo = "xyz";
and/or
context.parameter['foo'] = "xyz";
>
> We can get back the value in the authenticators( executed after this
> definition) by calling context.getScriptParameter("foo")
>
> I have developed a POC for this. I have created a new map in the
> "AuthenticationContext" to save these parameters.
>
> Please share your thoughts about this implementation.
>
> thanks,
> Senthalan.
>
>
> *Senthalan Kanagalingam*
> *Software Engineer - WSO2 Inc.*
> *Mobile : +94 (0) 77 18 77 466*
>
>
--
*Pulasthi Mahawithana*
Associate Technical Lead
WSO2 Inc., http://wso2.com/
Mobile: +94-71-5179022
Blog: https://medium.com/@pulasthi7/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
