[Dev] IDENTITY-6405 seems to be a duplicate of IDENTITY-3966

[Johann Nallathamby]

Hi Nila,

IDENTITY-6405 seems to be a duplicate of IDENTITY-3966. At least they seem
to be very much related. Therefore I have resolved as duplicate. Please
reopen if that isn't the case.

Regards,
Johann.

-- Forwarded message --
From: Nilasini Thirunavukkarasu (JIRA) 
Date: Mon, Sep 11, 2017 at 2:05 PM
Subject: [Carbon-jira] [jira] (IDENTITY-6405) Could able to degrade the
permission of the logged in user's role it makes some unexpected behaviours
To: carbon-j...@wso2.org


Nilasini Thirunavukkarasu

*created* an issue

WSO2 Identity Server  / [image: Bug]
 IDENTITY-6405

Could able to degrade the permission of the logged in user's role it makes
some unexpected behaviours 
Issue Type: [image: Bug] Bug
Affects Versions: 5.4.0-Alpha2
Assignee: Darshana Gunawardana

Attachments: first_window, second_window.png
Components: user-mgt
Created: 11/Sep/17 2:04 PM
Fix Versions: 5.4.0-GA
Priority: [image: Highest] Highest
Reporter: Nilasini Thirunavukkarasu


1) Add a role with all permission
2) Assign the role to a user (say the user as nila)
3) Try to logged in with nila
4) Update the role by un tick all the permission or keep only login
permission
5) See the attachment for the output. (Attachments are added for the
scenario "keeping only login permission")
[image: Add Comment]
 Add Comment


This message was sent by Atlassian JIRA (v7.2.2#72004-sha1:9d51328)
[image: Atlassian logo]

___
Carbon-jira mailing list
carbon-j...@wso2.org
https://wso2.org/cgi-bin/mailman/listinfo/carbon-jira




-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Public JIRA resolved as Not A Bug without Reason

[Sathya Bandara]

Hi Johann,

Sorry I have missed it and thanks for pointing out. This issue occurred due
to a misconfiguration. Need to enable JIT provisioning for federated users
before they can be outbound provisioned with this setup. Will update the
ticket with the reason of resolution.

Thanks,
Sathya

On Sat, Sep 16, 2017 at 6:40 PM, Johann Nallathamby  wrote:

> Sathya/IAM Folks,
>
> It is not acceptable to resolve JIRAs without any reason. Can we please
> include the reason as why it is not a bug? To me it looks like a clear bug.
>
> [1] https://wso2.org/jira/browse/IDENTITY-6375
>
> Thanks & Regards,
> Johann.
>
> --
>
> *Johann Dilantha Nallathamby*
> Senior Lead Solutions Engineer
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile - *+9476950*
> Blog - *http://nallaa.wordpress.com *
>



-- 
Sathya Bandara
Software Engineer
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421 <+94%2071%20411%205032>

<+94%2071%20411%205032>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] Public JIRA resolved as Not A Bug without Reason

[Johann Nallathamby]

Sathya/IAM Folks,

It is not acceptable to resolve JIRAs without any reason. Can we please
include the reason as why it is not a bug? To me it looks like a clear bug.

[1] https://wso2.org/jira/browse/IDENTITY-6375

Thanks & Regards,
Johann.

-- 

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [IS] Shall We Link Corresponding IS Documentation as Context Sensitive Help Pages in IS Management Console?

[Johann Nallathamby]

On Tue, Sep 12, 2017 at 5:01 PM, Johann Nallathamby  wrote:

> IMO Help link are good for a public facing application. E.g. API Store,
> Google Apps, etc. I don't think for a administrator application help link
> is necessary. Administrator applications are generally accompanied with a
> manual.
>

Just to be clear, what I meant is other large software ship with large
physical manuals or pdfs. So linking documentation from website is not
something I see commonly. And also it's going to be very difficult to find
and link specific sections. If linking documentation is going to be worse
experience than what is there now we shouldn't do it.

Having help pages was a good idea in the begining. But we haven't updated
it for a long time. So although updating the help links will be ideal,
given the time we have in our hand removing the links would be the optimal
solution if we want to fix this IMHO.


>
> Just my opinion.
>
> Regards,
> Johann.
>
> On Tue, Sep 12, 2017 at 4:43 PM, Thilina Madumal 
> wrote:
>
>> Hi Samuel,
>>
>> On Tue, Sep 12, 2017 at 9:38 AM, Samuel Gnaniah  wrote:
>>
>>> If the user needs to refer to the documentation to fill a form in the
>>> UI, that means the UI is not intuitive enough for the user. Better UX is a
>>> better and more sustainable solution, even if it means a wider set of
>>> changes in the short term.
>>>
>>
>> I sugessted this idea in an earlier reply to this thread. But as we
>> consider the practical perspective I would like to make some changes to
>> that idea.
>>
>>1. I don't stand with removing the help links completely. I would
>>rather (as minoli have sugested) go with linking IS documentation with
>>those links.
>>2. Making UI intuitive is a good option but it is a progressive
>>effort. On the other hand even though we achieved it we can't let go of
>>help documentation because it is not feasible to achieve that level of UI
>>intuitivity.
>>
>>
>>> --
>>>
>>> *Samuel Gnaniah*
>>> Lead Technical Writer
>>>
>>> WSO2 (pvt.) Ltd.
>>> Colombo, Sri Lanka
>>> (+94) 773131798 <+94%2077%20313%201798>
>>>
>>> On Tue, Sep 12, 2017 at 9:31 AM, Minoli Perera  wrote:
>>>
 IMO we should link the specific documentation pages related to the page
 topics without completely removing help link, then if the user needs help
 s/he need not search for the related content. Even though It is not
 accessible without internet for most of the cases it will be helpful.

 Thanks,
 Minoli

 On Tue, Sep 5, 2017 at 2:26 PM, Darshana Gunawardana  wrote:

> +1 to remove this.
>
> This is something comes from kernel right? So this is something has to
> agree with all products.
>
> Are we ok to remove this in a kernel patch release?
>
> On Tue, Sep 5, 2017 at 1:58 PM, Shiraz Azad  wrote:
>
>> Agree with Thilina. At the same time, we should make sure we dont
>> clutter the UI with explaining notes. In that case, a UI guide will be
>> really effective. +1 for that.
>>
>> Thanks
>> Shiraz
>>
>> On Mon, Sep 4, 2017 at 10:41 AM, Thilina Madumal > > wrote:
>>
>>> Hi all,
>>>
>>> For the 5.4.0 we have to go with the assumption that the current
>>> Implementation of the UI, self-explain enough.
>>> With that assumption, we can go ahead and can remove the help links.
>>> WDYT?
>>>
>>> Making UI self-explain better can be achieved in the 5.5.0 release
>>> since there is a plan to re-write the UI.
>>> For that, I suggest implementing something like UI guide (something
>>> similar to what APIM has done, IMO it is pretty effective) when a user
>>> starts a fresh pack.
>>>
>>> Regards,
>>> Thilina.
>>>
>>> On Sat, Sep 2, 2017 at 8:14 AM, Shiraz Azad  wrote:
>>>
 +1. for removing links and making the UI self explained.

 Shiraz


 On Thu, Aug 31, 2017 at 7:07 PM, Thilina Madumal <
 thilina...@wso2.com> wrote:

> +1 to remove the links as Johann has suggested.
>
> Regards,
> Thilina.
>
> On Thu, Aug 31, 2017 at 11:40 AM, Johann Nallathamby <
> joh...@wso2.com> wrote:
>
>> +1 to remove these links. I think better UX is the solution than
>> asking users to read more docs.
>>
>> Regards,
>> Johann.
>>
>> On Thu, Aug 31, 2017 at 11:04 AM, Samuel Gnaniah > > wrote:
>>
>>> Our strategy here is to remove these help links and walk through
>>> the UI with the dev team to make the UIs and forms easier to 
>>> configure
>>> without requiring additional documentation. This is the stragety we 
>>> are
>>> 

Re: [Dev] Avoid Invoking REST endpoints from SSO login page

[Johann Nallathamby]

On Sat, Sep 16, 2017 at 1:46 PM, Farasath Ahamed  wrote:

>
>
>
> On Sat, Sep 16, 2017 at 1:38 PM, Johann Nallathamby 
> wrote:
>
>> I also have the same concerns as Hasintha. The only viable solution seems
>> to be Pulasthi's which is to do the HEAD call to a URL which we know that
>> doesn't consume much resources. If needed we can even introduce a resource
>> like that for this purpose if already not available. It's kind of like
>> having a ping service right? And also disable the client following
>> redirects.
>>
>
> If we are doing a HEAD call, we need to make sure to hostname verification
> configuration set at server level. Otherwise if someone wants to use our
> authentication endpoint they will be forced to fix certs etc. when trying
> with a hostname although there is flag to switch off hostname verifications.
>
> So far we only faced this situation(forced to changes certs when using
> with a hostname) only for dashboard logins since this HEAD was done
> specifically if the SP was dashboard. Now that we have enabled this for all
> service providers fixing the hostname verification will be important.
>

Yes. This needs to be fixed in IS as in other products. IINM APIM has fixed
this in their entire product. We need to have a util method in
identity-core and change every component that needs to open a https
connection outside to use this utility to create a connection.

However, for this particular issue I think there is an alternative. We can
do the HEAD call to "http://localhost; in the default pack. The ping URL
can be configured in web.xml. Anyone who sets up this webapp in a external
web container can change the web.xml configuration. They can use the
external DNS or internal DNS, which ever way they want it to work.

This will make sure our objectives are met. I.e. minimal configuration for
OOTB usage for better UX. And ability host the webapp in an external web
container.

Do you see problem?

Regards,
Johann.


>
>
>>
>> On Tue, Sep 5, 2017 at 10:25 PM, Hasintha Indrajee 
>> wrote:
>>
>>> Can we alter a config inside webapp easily ? I mean if another product
>>> wants to change the config in order to change the OOTB behaviour, it has to
>>> extract and change the config at product build time. Is this
>>> straightforward to a config inside a webapp ? On the other hand we cannot
>>> move this config to a file which stays out of the webapp. It's not correct
>>> since authentication endpoint should be ideally self contained.
>>>
>>> On Tue, Sep 5, 2017 at 10:01 PM, Nuwandi Wickramasinghe <
>>> nuwan...@wso2.com> wrote:
>>>


 On Tue, Sep 5, 2017 at 12:59 PM, Farasath Ahamed 
 wrote:

>
>
> On Tue, Sep 5, 2017 at 12:39 PM, Pulasthi Mahawithana <
> pulast...@wso2.com> wrote:
>
>>
>>
>> On Mon, Sep 4, 2017 at 2:44 PM, Hasintha Indrajee 
>> wrote:
>>
>>> I think we must avoid this if this is just to check whether the
>>> endpoint exists or not. This is anyway a costly operation. Head will 
>>> only
>>> reduce the transport cost. Otherwise when the head request reaches back
>>> end, it does the relevant operation treating the request as a GET and 
>>> avoid
>>> responding with actual payload. In our case this is very costly because
>>> within these calls, there are user store accesses and multiple other DB
>>> accesses.
>>>
>>
>> We'll need that check (or some other way) to check whether the
>> identity mgt webapp exists and deployed since some products don't ship it
>> by default. And yes, we need to get rid of calling an endpoint which does
>> any heavy work. So shall we do the HEAD to a page which does not do any
>> heavy work? May be to "accountrecoveryendpoint/error.jsp"?
>>
>
> Wouldn't it be easier if we do this with a config.
> ie. By default we do not show these links. If any product ships the
> account recovery endpoint  and they want to show the recovery links for 
> all
> service provider logins, then they override this config at product level.
>
 +1
 Actually there is "IdentityManagementEndpointContextURL" parameter
 configured in authenticationendpoint web.xml. Value of this parameter is
 used to determine the recoveryendpoint url. As per the current
 implementation, if this parameter is not configured, we retrieve the webapp
 url by calling *IdentityUtil.getServerURL("/accountrecoveryendpoint",
 true, true). *Can't we avoid showing the links if
 *IdentityManagementEndpointContextURL* is not configured in
 authentication endpoint? In the default pack, this parameter is commented
 out. So anyone who needs it can un comment it.

 However with this implementation, the default behavior of dashboard
 login page would change.

>
> Another reason for this suggestion is that, upto IS 

Re: [Dev] Dynamic client registration request fails due to no user information in the request header.

[Johann Nallathamby]

On Sat, Sep 16, 2017 at 1:37 PM, Farasath Ahamed  wrote:

>
>
>
>
> On Sat, Sep 16, 2017 at 1:21 PM, Johann Nallathamby 
> wrote:
>
>> Tenant domain of the application should always be read from the resource
>> path - i.e. URL.
>>
>> We can't read it from the user since we will have to support SaaS mode,
>> which is to authenticate with a super tenant user and create the
>> application in a tenant.
>>
>
>
> Can we really do this? Authenticate from super tenant credentials and
> create an application in tenant?
>
> Our token endpoint derives the app's tenant domain from the tenantDomain
> of the user who created the app[1]. The assumption behind is that we can
> create apps across tenants. ie. A user from super tenant cannot go and
> create an app in a tenant.
>

I didn't think much about the DCR use case. I was talking in general. First
we need to think if SaaS scenario is applicable for DCR. If it is we need
to fix above limitation :). AFAIK above limitation comes because of the
limitation in the schema we have. And may be some model objects. Nothing
else. This is because OAuth2 was written way before IS 5.0.0 which
introduced SaaS concept. May be we even don't need to fix it immediately.
But we must follow same security pattern for all Rest endpoints, regardless
of limitations within the component.


>
>
> [1] https://github.com/wso2-extensions/identity-inbound-auth
> -oauth/blob/master/components/org.wso2.carbon.identity.
> oauth/src/main/java/org/wso2/carbon/identity/oauth2/token/A
> ccessTokenIssuer.java#L129
>
>
>>
>> Please note that this is a standard pattern we follow in IS now, for
>> almost all endpoints. Therefore no one could be ignorant about it. Any new
>> Rest  endpoint development must follow the same security pattern. We do
>> this with the help of the Authn/Authz valve implemented by Harsha.
>>
>> Regards,
>> Johann.
>>
>> On Sat, Sep 16, 2017 at 1:11 PM, Hasintha Indrajee 
>> wrote:
>>
>>> Just asking for my knowledge,
>>>
>>> How do we identify the tenant domain of the application ? Do we have it
>>> in the context path ?, do we get it from user ?, or do we have anyway to
>>> convey it within the body (by appending to something) ? In a case if we get
>>> it from the identified user, how are we going to identify it from a request
>>> without any authentication mechanism ?.
>>>
>>> On Sat, Sep 16, 2017 at 12:36 PM, Gayan Gunawardana 
>>> wrote:
>>>


 On Fri, Sep 15, 2017 at 2:47 PM, Hasini Witharana 
 wrote:

> Hi,
>
> In OIDC dynamic client registration, in the request header we need to
> send an already existing user and the password to register a client in 
> WSO2
> Identity server.In OIDC specification[1], It is not mandatory to send user
> details to register a client.
>
> When running the OIDC test suite for dynamic profile, test suite does
> not send any user details in the header. So we can't create any client and
> the test fails.
>
> For that issue if any user details are not provided in the
> registration request we can assign an anonymous user(*wso2*.
> *anonymous*.*user*) and register the client.
>
 IMO correct design should be completely remove the requirement of
 having a user. If we use *"wso2*.*anonymous*.*user" *some application
 may have real username and some application may have *"wso2*.
 *anonymous*.*user" *which end up with inconsistency.
 Also need to think about creating a role per service provider if any
 user doesn't have that role.

>
> [1] - https://openid.net/specs/openid-connect-registration-1_0.html
>
> --
>
> *Hasini Witharana*
> Software Engineering Intern | WSO2
>
>
> *Email : hasi...@wso2.com *
>
> *Mobile : +94713850143 <+94%2071%20385%200143>[image:
> http://wso2.com/signature] *
>
> --
> You received this message because you are subscribed to the Google
> Groups "WSO2 Engineering Group" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to engineering-group+unsubscr...@wso2.com.
> For more options, visit https://groups.google.com/a/wso2.com/d/optout.
>



 --
 Gayan Gunawardana
 Senior Software Engineer; WSO2 Inc.; http://wso2.com/
 Email: ga...@wso2.com
 Mobile: +94 (71) 8020933

 --
 You received this message because you are subscribed to the Google
 Groups "WSO2 Engineering Group" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to engineering-group+unsubscr...@wso2.com.
 For more options, visit https://groups.google.com/a/wso2.com/d/optout.

>>>
>>>
>>>
>>> --
>>> Hasintha Indrajee
>>> WSO2, Inc.
>>> Mobile:+94 771892453 <+94%2077%20189%202453>
>>>
>>>
>>
>>
>> --
>> Thanks & 

Re: [Dev] Avoid Invoking REST endpoints from SSO login page

[Farasath Ahamed]

On Sat, Sep 16, 2017 at 1:38 PM, Johann Nallathamby  wrote:

> I also have the same concerns as Hasintha. The only viable solution seems
> to be Pulasthi's which is to do the HEAD call to a URL which we know that
> doesn't consume much resources. If needed we can even introduce a resource
> like that for this purpose if already not available. It's kind of like
> having a ping service right? And also disable the client following
> redirects.
>

If we are doing a HEAD call, we need to make sure to hostname verification
configuration set at server level. Otherwise if someone wants to use our
authentication endpoint they will be forced to fix certs etc. when trying
with a hostname although there is flag to switch off hostname verifications.

So far we only faced this situation(forced to changes certs when using with
a hostname) only for dashboard logins since this HEAD was done specifically
if the SP was dashboard. Now that we have enabled this for all service
providers fixing the hostname verification will be important.



>
> On Tue, Sep 5, 2017 at 10:25 PM, Hasintha Indrajee 
> wrote:
>
>> Can we alter a config inside webapp easily ? I mean if another product
>> wants to change the config in order to change the OOTB behaviour, it has to
>> extract and change the config at product build time. Is this
>> straightforward to a config inside a webapp ? On the other hand we cannot
>> move this config to a file which stays out of the webapp. It's not correct
>> since authentication endpoint should be ideally self contained.
>>
>> On Tue, Sep 5, 2017 at 10:01 PM, Nuwandi Wickramasinghe <
>> nuwan...@wso2.com> wrote:
>>
>>>
>>>
>>> On Tue, Sep 5, 2017 at 12:59 PM, Farasath Ahamed 
>>> wrote:
>>>


 On Tue, Sep 5, 2017 at 12:39 PM, Pulasthi Mahawithana <
 pulast...@wso2.com> wrote:

>
>
> On Mon, Sep 4, 2017 at 2:44 PM, Hasintha Indrajee 
> wrote:
>
>> I think we must avoid this if this is just to check whether the
>> endpoint exists or not. This is anyway a costly operation. Head will only
>> reduce the transport cost. Otherwise when the head request reaches back
>> end, it does the relevant operation treating the request as a GET and 
>> avoid
>> responding with actual payload. In our case this is very costly because
>> within these calls, there are user store accesses and multiple other DB
>> accesses.
>>
>
> We'll need that check (or some other way) to check whether the
> identity mgt webapp exists and deployed since some products don't ship it
> by default. And yes, we need to get rid of calling an endpoint which does
> any heavy work. So shall we do the HEAD to a page which does not do any
> heavy work? May be to "accountrecoveryendpoint/error.jsp"?
>

 Wouldn't it be easier if we do this with a config.
 ie. By default we do not show these links. If any product ships the
 account recovery endpoint  and they want to show the recovery links for all
 service provider logins, then they override this config at product level.

>>> +1
>>> Actually there is "IdentityManagementEndpointContextURL" parameter
>>> configured in authenticationendpoint web.xml. Value of this parameter is
>>> used to determine the recoveryendpoint url. As per the current
>>> implementation, if this parameter is not configured, we retrieve the webapp
>>> url by calling *IdentityUtil.getServerURL("/accountrecoveryendpoint",
>>> true, true). *Can't we avoid showing the links if
>>> *IdentityManagementEndpointContextURL* is not configured in
>>> authentication endpoint? In the default pack, this parameter is commented
>>> out. So anyone who needs it can un comment it.
>>>
>>> However with this implementation, the default behavior of dashboard
>>> login page would change.
>>>

 Another reason for this suggestion is that, upto IS 5.3.0 we only
 showed the recovery related links when login into user dashboard only. So
 this is essentially a change in the default behaviour of the product where
 we now show the recovery links in the login page for all service providers
 (not just the dashboard). So if someone wants to stick to the previous
 behaviour they should have a way to do so (ie. maintain backward
 compatibility).

>>>

>
>
>>
>> On Fri, Aug 18, 2017 at 4:39 PM, Isura Karunaratne 
>> wrote:
>>
>>>
>>> On Fri, Aug 18, 2017 at 4:33 PM Malithi Edirisinghe <
>>> malit...@wso2.com> wrote:
>>>
 On Fri, Aug 18, 2017 at 4:02 PM, Isura Karunaratne 
 wrote:

> Hi Malithi,
>
> On Fri, Aug 18, 2017 at 3:41 PM, Malithi Edirisinghe <
> malit...@wso2.com> wrote:
>
>>
>>
>> On Fri, Aug 18, 2017 at 12:31 PM, Nuwandi Wickramasinghe <
>> nuwan...@wso2.com> 

Re: [Dev] Avoid Invoking REST endpoints from SSO login page

[Johann Nallathamby]

I also have the same concerns as Hasintha. The only viable solution seems
to be Pulasthi's which is to do the HEAD call to a URL which we know that
doesn't consume much resources. If needed we can even introduce a resource
like that for this purpose if already not available. It's kind of like
having a ping service right? And also disable the client following
redirects.

On Tue, Sep 5, 2017 at 10:25 PM, Hasintha Indrajee 
wrote:

> Can we alter a config inside webapp easily ? I mean if another product
> wants to change the config in order to change the OOTB behaviour, it has to
> extract and change the config at product build time. Is this
> straightforward to a config inside a webapp ? On the other hand we cannot
> move this config to a file which stays out of the webapp. It's not correct
> since authentication endpoint should be ideally self contained.
>
> On Tue, Sep 5, 2017 at 10:01 PM, Nuwandi Wickramasinghe  > wrote:
>
>>
>>
>> On Tue, Sep 5, 2017 at 12:59 PM, Farasath Ahamed 
>> wrote:
>>
>>>
>>>
>>> On Tue, Sep 5, 2017 at 12:39 PM, Pulasthi Mahawithana <
>>> pulast...@wso2.com> wrote:
>>>


 On Mon, Sep 4, 2017 at 2:44 PM, Hasintha Indrajee 
 wrote:

> I think we must avoid this if this is just to check whether the
> endpoint exists or not. This is anyway a costly operation. Head will only
> reduce the transport cost. Otherwise when the head request reaches back
> end, it does the relevant operation treating the request as a GET and 
> avoid
> responding with actual payload. In our case this is very costly because
> within these calls, there are user store accesses and multiple other DB
> accesses.
>

 We'll need that check (or some other way) to check whether the identity
 mgt webapp exists and deployed since some products don't ship it by
 default. And yes, we need to get rid of calling an endpoint which does any
 heavy work. So shall we do the HEAD to a page which does not do any heavy
 work? May be to "accountrecoveryendpoint/error.jsp"?

>>>
>>> Wouldn't it be easier if we do this with a config.
>>> ie. By default we do not show these links. If any product ships the
>>> account recovery endpoint  and they want to show the recovery links for all
>>> service provider logins, then they override this config at product level.
>>>
>> +1
>> Actually there is "IdentityManagementEndpointContextURL" parameter
>> configured in authenticationendpoint web.xml. Value of this parameter is
>> used to determine the recoveryendpoint url. As per the current
>> implementation, if this parameter is not configured, we retrieve the webapp
>> url by calling *IdentityUtil.getServerURL("/accountrecoveryendpoint",
>> true, true). *Can't we avoid showing the links if
>> *IdentityManagementEndpointContextURL* is not configured in
>> authentication endpoint? In the default pack, this parameter is commented
>> out. So anyone who needs it can un comment it.
>>
>> However with this implementation, the default behavior of dashboard login
>> page would change.
>>
>>>
>>> Another reason for this suggestion is that, upto IS 5.3.0 we only showed
>>> the recovery related links when login into user dashboard only. So this is
>>> essentially a change in the default behaviour of the product where we now
>>> show the recovery links in the login page for all service providers (not
>>> just the dashboard). So if someone wants to stick to the previous behaviour
>>> they should have a way to do so (ie. maintain backward compatibility).
>>>
>>
>>>


>
> On Fri, Aug 18, 2017 at 4:39 PM, Isura Karunaratne 
> wrote:
>
>>
>> On Fri, Aug 18, 2017 at 4:33 PM Malithi Edirisinghe <
>> malit...@wso2.com> wrote:
>>
>>> On Fri, Aug 18, 2017 at 4:02 PM, Isura Karunaratne 
>>> wrote:
>>>
 Hi Malithi,

 On Fri, Aug 18, 2017 at 3:41 PM, Malithi Edirisinghe <
 malit...@wso2.com> wrote:

>
>
> On Fri, Aug 18, 2017 at 12:31 PM, Nuwandi Wickramasinghe <
> nuwan...@wso2.com> wrote:
>
>> Looks like http calls are done to validate the endpoint url. Do
>> we need this validation before showing the link?
>>
>> Shall we remove these calls and directly show the hyper link?
>>
>
> So here the validation is done as we are invoking another webapp.
> So that this check make sure a broken link is never to be shown in 
> this
> login page. Moreover, this is just a HEAD call so I don't think 
> invoking
> that impacts the login page performance, because the actual page is 
> not
> getting rendered here.
> The other thing is these webapps are coming from two features, so
> IMO, we cannot directly couple them together.
>

Re: [Dev] Dynamic client registration request fails due to no user information in the request header.

[Farasath Ahamed]

On Sat, Sep 16, 2017 at 1:21 PM, Johann Nallathamby  wrote:

> Tenant domain of the application should always be read from the resource
> path - i.e. URL.
>
> We can't read it from the user since we will have to support SaaS mode,
> which is to authenticate with a super tenant user and create the
> application in a tenant.
>


Can we really do this? Authenticate from super tenant credentials and
create an application in tenant?

Our token endpoint derives the app's tenant domain from the tenantDomain of
the user who created the app[1]. The assumption behind is that we can
create apps across tenants. ie. A user from super tenant cannot go and
create an app in a tenant.


[1]
https://github.com/wso2-extensions/identity-inbound-auth-oauth/blob/master/components/org.wso2.carbon.identity.oauth/src/main/java/org/wso2/carbon/identity/oauth2/token/AccessTokenIssuer.java#L129


>
> Please note that this is a standard pattern we follow in IS now, for
> almost all endpoints. Therefore no one could be ignorant about it. Any new
> Rest  endpoint development must follow the same security pattern. We do
> this with the help of the Authn/Authz valve implemented by Harsha.
>
> Regards,
> Johann.
>
> On Sat, Sep 16, 2017 at 1:11 PM, Hasintha Indrajee 
> wrote:
>
>> Just asking for my knowledge,
>>
>> How do we identify the tenant domain of the application ? Do we have it
>> in the context path ?, do we get it from user ?, or do we have anyway to
>> convey it within the body (by appending to something) ? In a case if we get
>> it from the identified user, how are we going to identify it from a request
>> without any authentication mechanism ?.
>>
>> On Sat, Sep 16, 2017 at 12:36 PM, Gayan Gunawardana 
>> wrote:
>>
>>>
>>>
>>> On Fri, Sep 15, 2017 at 2:47 PM, Hasini Witharana 
>>> wrote:
>>>
 Hi,

 In OIDC dynamic client registration, in the request header we need to
 send an already existing user and the password to register a client in WSO2
 Identity server.In OIDC specification[1], It is not mandatory to send user
 details to register a client.

 When running the OIDC test suite for dynamic profile, test suite does
 not send any user details in the header. So we can't create any client and
 the test fails.

 For that issue if any user details are not provided in the registration
 request we can assign an anonymous user(*wso2*.*anonymous*.*user*) and
 register the client.

>>> IMO correct design should be completely remove the requirement of having
>>> a user. If we use *"wso2*.*anonymous*.*user" *some application may have
>>> real username and some application may have *"wso2*.*anonymous*.*user" 
>>> *which
>>> end up with inconsistency.
>>> Also need to think about creating a role per service provider if any
>>> user doesn't have that role.
>>>

 [1] - https://openid.net/specs/openid-connect-registration-1_0.html

 --

 *Hasini Witharana*
 Software Engineering Intern | WSO2


 *Email : hasi...@wso2.com *

 *Mobile : +94713850143 <+94%2071%20385%200143>[image:
 http://wso2.com/signature] *

 --
 You received this message because you are subscribed to the Google
 Groups "WSO2 Engineering Group" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to engineering-group+unsubscr...@wso2.com.
 For more options, visit https://groups.google.com/a/wso2.com/d/optout.

>>>
>>>
>>>
>>> --
>>> Gayan Gunawardana
>>> Senior Software Engineer; WSO2 Inc.; http://wso2.com/
>>> Email: ga...@wso2.com
>>> Mobile: +94 (71) 8020933
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "WSO2 Engineering Group" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to engineering-group+unsubscr...@wso2.com.
>>> For more options, visit https://groups.google.com/a/wso2.com/d/optout.
>>>
>>
>>
>>
>> --
>> Hasintha Indrajee
>> WSO2, Inc.
>> Mobile:+94 771892453 <+94%2077%20189%202453>
>>
>>
>
>
> --
> Thanks & Regards,
>
> *Johann Dilantha Nallathamby*
> Senior Lead Solutions Engineer
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile - *+9476950*
> Blog - *http://nallaa.wordpress.com *
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Dynamic client registration request fails due to no user information in the request header.

[Johann Nallathamby]

Tenant domain of the application should always be read from the resource
path - i.e. URL.

We can't read it from the user since we will have to support SaaS mode,
which is to authenticate with a super tenant user and create the
application in a tenant.

Please note that this is a standard pattern we follow in IS now, for almost
all endpoints. Therefore no one could be ignorant about it. Any new Rest
 endpoint development must follow the same security pattern. We do this
with the help of the Authn/Authz valve implemented by Harsha.

Regards,
Johann.

On Sat, Sep 16, 2017 at 1:11 PM, Hasintha Indrajee 
wrote:

> Just asking for my knowledge,
>
> How do we identify the tenant domain of the application ? Do we have it in
> the context path ?, do we get it from user ?, or do we have anyway to
> convey it within the body (by appending to something) ? In a case if we get
> it from the identified user, how are we going to identify it from a request
> without any authentication mechanism ?.
>
> On Sat, Sep 16, 2017 at 12:36 PM, Gayan Gunawardana 
> wrote:
>
>>
>>
>> On Fri, Sep 15, 2017 at 2:47 PM, Hasini Witharana 
>> wrote:
>>
>>> Hi,
>>>
>>> In OIDC dynamic client registration, in the request header we need to
>>> send an already existing user and the password to register a client in WSO2
>>> Identity server.In OIDC specification[1], It is not mandatory to send user
>>> details to register a client.
>>>
>>> When running the OIDC test suite for dynamic profile, test suite does
>>> not send any user details in the header. So we can't create any client and
>>> the test fails.
>>>
>>> For that issue if any user details are not provided in the registration
>>> request we can assign an anonymous user(*wso2*.*anonymous*.*user*) and
>>> register the client.
>>>
>> IMO correct design should be completely remove the requirement of having
>> a user. If we use *"wso2*.*anonymous*.*user" *some application may have
>> real username and some application may have *"wso2*.*anonymous*.*user" *which
>> end up with inconsistency.
>> Also need to think about creating a role per service provider if any user
>> doesn't have that role.
>>
>>>
>>> [1] - https://openid.net/specs/openid-connect-registration-1_0.html
>>>
>>> --
>>>
>>> *Hasini Witharana*
>>> Software Engineering Intern | WSO2
>>>
>>>
>>> *Email : hasi...@wso2.com *
>>>
>>> *Mobile : +94713850143 <+94%2071%20385%200143>[image:
>>> http://wso2.com/signature] *
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "WSO2 Engineering Group" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to engineering-group+unsubscr...@wso2.com.
>>> For more options, visit https://groups.google.com/a/wso2.com/d/optout.
>>>
>>
>>
>>
>> --
>> Gayan Gunawardana
>> Senior Software Engineer; WSO2 Inc.; http://wso2.com/
>> Email: ga...@wso2.com
>> Mobile: +94 (71) 8020933
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "WSO2 Engineering Group" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to engineering-group+unsubscr...@wso2.com.
>> For more options, visit https://groups.google.com/a/wso2.com/d/optout.
>>
>
>
>
> --
> Hasintha Indrajee
> WSO2, Inc.
> Mobile:+94 771892453 <+94%2077%20189%202453>
>
>


-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Dynamic client registration request fails due to no user information in the request header.

[Hasintha Indrajee]

Just asking for my knowledge,

How do we identify the tenant domain of the application ? Do we have it in
the context path ?, do we get it from user ?, or do we have anyway to
convey it within the body (by appending to something) ? In a case if we get
it from the identified user, how are we going to identify it from a request
without any authentication mechanism ?.

On Sat, Sep 16, 2017 at 12:36 PM, Gayan Gunawardana  wrote:

>
>
> On Fri, Sep 15, 2017 at 2:47 PM, Hasini Witharana 
> wrote:
>
>> Hi,
>>
>> In OIDC dynamic client registration, in the request header we need to
>> send an already existing user and the password to register a client in WSO2
>> Identity server.In OIDC specification[1], It is not mandatory to send user
>> details to register a client.
>>
>> When running the OIDC test suite for dynamic profile, test suite does not
>> send any user details in the header. So we can't create any client and the
>> test fails.
>>
>> For that issue if any user details are not provided in the registration
>> request we can assign an anonymous user(*wso2*.*anonymous*.*user*) and
>> register the client.
>>
> IMO correct design should be completely remove the requirement of having a
> user. If we use *"wso2*.*anonymous*.*user" *some application may have
> real username and some application may have *"wso2*.*anonymous*.*user" *which
> end up with inconsistency.
> Also need to think about creating a role per service provider if any user
> doesn't have that role.
>
>>
>> [1] - https://openid.net/specs/openid-connect-registration-1_0.html
>>
>> --
>>
>> *Hasini Witharana*
>> Software Engineering Intern | WSO2
>>
>>
>> *Email : hasi...@wso2.com *
>>
>> *Mobile : +94713850143 <+94%2071%20385%200143>[image:
>> http://wso2.com/signature] *
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "WSO2 Engineering Group" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to engineering-group+unsubscr...@wso2.com.
>> For more options, visit https://groups.google.com/a/wso2.com/d/optout.
>>
>
>
>
> --
> Gayan Gunawardana
> Senior Software Engineer; WSO2 Inc.; http://wso2.com/
> Email: ga...@wso2.com
> Mobile: +94 (71) 8020933
>
> --
> You received this message because you are subscribed to the Google Groups
> "WSO2 Engineering Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to engineering-group+unsubscr...@wso2.com.
> For more options, visit https://groups.google.com/a/wso2.com/d/optout.
>



-- 
Hasintha Indrajee
WSO2, Inc.
Mobile:+94 771892453
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Dynamic client registration request fails due to no user information in the request header.

[Gayan Gunawardana]

On Fri, Sep 15, 2017 at 2:47 PM, Hasini Witharana  wrote:

> Hi,
>
> In OIDC dynamic client registration, in the request header we need to send
> an already existing user and the password to register a client in WSO2
> Identity server.In OIDC specification[1], It is not mandatory to send user
> details to register a client.
>
> When running the OIDC test suite for dynamic profile, test suite does not
> send any user details in the header. So we can't create any client and the
> test fails.
>
> For that issue if any user details are not provided in the registration
> request we can assign an anonymous user(*wso2*.*anonymous*.*user*) and
> register the client.
>
IMO correct design should be completely remove the requirement of having a
user. If we use *"wso2*.*anonymous*.*user" *some application may have real
username and some application may have *"wso2*.*anonymous*.*user" *which
end up with inconsistency.
Also need to think about creating a role per service provider if any user
doesn't have that role.

>
> [1] - https://openid.net/specs/openid-connect-registration-1_0.html
>
> --
>
> *Hasini Witharana*
> Software Engineering Intern | WSO2
>
>
> *Email : hasi...@wso2.com *
>
> *Mobile : +94713850143 <+94%2071%20385%200143>[image:
> http://wso2.com/signature] *
>
> --
> You received this message because you are subscribed to the Google Groups
> "WSO2 Engineering Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to engineering-group+unsubscr...@wso2.com.
> For more options, visit https://groups.google.com/a/wso2.com/d/optout.
>



-- 
Gayan Gunawardana
Senior Software Engineer; WSO2 Inc.; http://wso2.com/
Email: ga...@wso2.com
Mobile: +94 (71) 8020933
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev