from:"Farasath Ahamed"

Re: [Dev] Adding auth_time claim to the ID token by default

2020-11-15 Thread Farasath Ahamed

On Mon, Nov 16, 2020, 12:56 PM Yasas Ramanayake (Intern) 
wrote:

> Hi all,
>
> I'm in the process of fixing issue [1]
> In our current implementation auth_time claim is sent in the ID token only
> if it's requested by the client as an essential claim or when a max_age
> request is made. However in one of the OIDC conformance suite test cases
> they expect the ID token to have auth_time even without explicitly
> requesting for it. Sending auth_time is optional according to specification
> [2].
>
> We can consider this as an improvement to our implementation and add the
> auth_time by default to the id_token . Please share if you have any
> concerns/suggestions regarding this.
>
> [1] https://github.com/wso2/product-is/issues/10391
> [2] https://openid.net/specs/openid-connect-core-1_0.html#IDToken
>
>
> Regards,
> --
> Yasas Ramanayake | Intern -  Engineering | WSO2 Inc.
> (m) +94717380767 | (w) +94115712082 | (e) yas...@wso2.com
> [image: https://wso2.com/signature] 
>
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] WSO2 Committers += Gangani Chamika

2020-10-01 Thread Farasath Ahamed

Hi All,

It's my pleasure to announce Gangani Chamika as a WSO2 Committer. She has
been a valuable contributor to the WSO2 Identity & Access Management Team.
In recognition of her contribution to WSO2, she has been voted as
a WSO2 committer.

Congratulations Gangani and keep up the good work...!!!


Thanks & Regards,
Farasath Ahamed
Identity and Access Management Team, WSO2 Inc.: http://wso2.com
Mobile: +94777603866
Blog: https://farasath.blogspot.com / https://medium.com/@farasath
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] How to disable commonAuthId cookie.

2020-07-18 Thread Farasath Ahamed

If your requirement is to force the user to login regardless of whether a
session exists or not during oauth2 login, then you can try sending
'prompt=login' additional query param in the authorize request.

Is there any other reason for you to avoid setting the commonauthId cookie
other than forcing the user to login?

Regards,
Farasath

On Sat, Jul 18, 2020, 10:00 AM Shiva Kumar K R 
wrote:

> Hi Team,
> I am using WSO2 Identity Server 5.3.0 for OAuth2 Authorization Grant Type
> Flow. I want to login every time in the browser when the Authorization
> endpoint is requested, because of the commonAuthId Cookie I can't. Is there
> anyway to disable/remove the commonAuthId cookie.
>
> --
> Gracias,
> Shiva Kumar K R
> __
> Software Engineer
> SecurelyShare Software Pvt Ltd 
> *Contact:* Linkedin
> 
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Iam-dev] [VOTE] Release WSO2 Identity Server 5.10.0 RC2

2020-03-11 Thread Farasath Ahamed

Hi,

Tested

1. Self-service functionalities of the user portal such as setup up 2nd
factor, setup up security device, change password, update profile
2. Passwordless authentication with Mac Fingerprint scanner
3. MFA with TOTP
4. Account Linking
5. Enrol TOTP in the login flow

[+] Stable - go ahead and release


On Sun, Mar 8, 2020 at 11:26 PM Janak Amarasena  wrote:

> Hi all,
>
> We are pleased to announce the second release candidate of WSO2 Identity
> Server 5.10.0.
>
>
> *New Features:*
>
>1. Passwordless authentication support
>2. An improved User Portal
>3. New RESTful APIs for user self-services and server management
>4. Scope based authorization for internal REST APIs
>5. Unique User ID support
>6. Tenant wise email-sender configuration
>
>
>
> *Fixes:*
> This release includes the following issue fixes and improvements:
>
>- 5.10.0-M1 <https://github.com/wso2/product-is/milestone/95?closed=1>
>- 5.10.0-M2 <https://github.com/wso2/product-is/milestone/96?closed=1>
>- 5.10.0-M3 <https://github.com/wso2/product-is/milestone/97?closed=1>
>- 5.10.0-M4 <https://github.com/wso2/product-is/milestone/98?closed=1>
>- 5.10.0-M5 <https://github.com/wso2/product-is/milestone/99?closed=1>
>- 5.10.0-M6 <https://github.com/wso2/product-is/milestone/100?closed=1>
>- 5.10.0-M7 <https://github.com/wso2/product-is/milestone/101?closed=1>
>- 5.10.0-M8 <https://github.com/wso2/product-is/milestone/102?closed=1>
>- 5.10.0-M9 <https://github.com/wso2/product-is/milestone/103?closed=1>
>- 5.10.0-Alpha
><https://github.com/wso2/product-is/milestone/104?closed=1>
>- 5.10.0-Alpha2
><https://github.com/wso2/product-is/milestone/105?closed=1>
>- 5.10.0-Alpha3
><https://github.com/wso2/product-is/milestone/106?closed=1>
>- 5.10.0-Beta
><https://github.com/wso2/product-is/milestone/107?closed=1>
>- 5.10.0-Beta2
><https://github.com/wso2/product-is/milestone/108?closed=1>
>- 5.10.0-Beta3
><https://github.com/wso2/product-is/milestone/109?closed=1>
>- 5.10.0-GA <https://github.com/wso2/product-is/milestone/92?closed=1>
>
>
> *Source and Distribution*
> The source and distribution
> <https://github.com/wso2/product-is/releases/download/v5.10.0-rc2/wso2is-5.10.0-rc2.zip>
>  are
> available at https://github.com/wso2/product-is/releases/tag/v5.10.0-rc2
>
>
> Please download the product, test it, and vote using the following
> convention.
> [+] Stable - go ahead and release
> [-] Broken - do not release (explain why)
>
>
> Thank you,
> WSO2 Identity and Access Management Team
>
> --
> *Janak Amarasena* | Senior Software Engineer | WSO2 Inc.
> (m) +9464144 | (w) +94112145345 | (e) ja...@wso2.com
>
>
> <https://wso2.com/signature>
> ___
> Iam-dev mailing list
> iam-...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/iam-dev
>


-- 
Farasath Ahamed
Associate Technical Lead, WSO2 Inc.: http://wso2.com
Mobile: +94777603866
Blog: https://farasath.blogspot.com / https://medium.com/@farasath
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Passing service provider object to the postDeleteHandler of the ApplicationMgtListener

2019-11-04 Thread Farasath Ahamed

On Fri, Nov 1, 2019 at 4:38 PM Gayashan Bombuwala 
wrote:

> Hi Johann,
>
> Both the new handler and the old handler will be called at the end[1] of
> deleteServiceProvider() execution.
> By the time that postDeleteHandler gets executed, the relevant Service
> Provider object will been already removed. Hence, we can't read the Service
> Provider object based on the name inside the postDeltedHandler.
> We have also deprecated[2] the old postDeleteHandler.
>

Instead of calling both old and new methods of the listener. Can't we add a
default implementation at the interface level like below for the new method,

default boolean doPostDeleteApplication(ServiceProvider serviceProvider,
String tenantDomain, String userName)
throws IdentityApplicationManagementException {
return doPostDeleteApplication(serviceProvider.getName(),
tenantDomain, userName);
}

and call only the new method doPostDeleteApplication(ServiceProvider
serviceProvider, String tenantDomain, String userName) at the OSGi service
level.

This way we consume the new API only and any listener written implementing
the deprecated method will also work without an issue.


> [1]
> https://github.com/wso2/carbon-identity-framework/blob/07c9b78564dbd4fd652ae323d3f3ef264cf5/components/application-mgt/org.wso2.carbon.identity.application.mgt/src/main/java/org/wso2/carbon/identity/application/mgt/ApplicationManagementServiceImpl.java#L746
> [2]
> https://github.com/wso2/carbon-identity-framework/blob/07c9b78564dbd4fd652ae323d3f3ef264cf5/components/application-mgt/org.wso2.carbon.identity.application.mgt/src/main/java/org/wso2/carbon/identity/application/mgt/listener/ApplicationMgtListener.java#L121
>
> Regards,
> Gayashan.
>
> On Fri, Nov 1, 2019 at 3:37 PM Johann Nallathamby  wrote:
>
>> Hi Gayashan,
>>
>> Though you introduce the method in the API, who calls the method? Now
>> that there are two methods is the ApplicationMgtService going to call both
>> the methods? Can't we read the Service Provider object based on the name
>> rather than introducing a new method for it?
>>
>> Regards,
>> Johann.
>>
>> On Fri, Oct 25, 2019 at 4:45 PM Gayashan Bombuwala 
>> wrote:
>>
>>> Hi all,
>>>
>>> Currently implementation of the postDeleteHandler[1] of
>>> ApplicationMgtListener only accepts the name of the service provider as a
>>> parameter. However the postCreateHandler[2] and postUpdateHandler[3] of the
>>> ApplicationMgtListener accepts the relevant Service Provider object as a
>>> parameter rather than just the service provider name.We will be introducing
>>> a new overloaded postDeleteHandler to the ApplicationMgtListener interface
>>> where the relevant Service Provider object get passed to the handler
>>> similar to the postCreateHandler[2] and postUpdateHandler[3] as the
>>> relevant Service Provider information is required for logging purposes.
>>>
>>> [1]
>>> https://github.com/wso2/carbon-identity-framework/blob/b95514a65960e75015855d343ebd9452c4ce6a2b/components/application-mgt/org.wso2.carbon.identity.application.mgt/src/main/java/org/wso2/carbon/identity/application/mgt/listener/ApplicationMgtListener.java#L117
>>>
>>> [2]
>>> https://github.com/wso2/carbon-identity-framework/blob/b95514a65960e75015855d343ebd9452c4ce6a2b/components/application-mgt/org.wso2.carbon.identity.application.mgt/src/main/java/org/wso2/carbon/identity/application/mgt/listener/ApplicationMgtListener.java#L69
>>>
>>> [3]
>>> https://github.com/wso2/carbon-identity-framework/blob/b95514a65960e75015855d343ebd9452c4ce6a2b/components/application-mgt/org.wso2.carbon.identity.application.mgt/src/main/java/org/wso2/carbon/identity/application/mgt/listener/ApplicationMgtListener.java#L93
>>>
>>> Thanks,
>>> --
>>> *Gayashan Bombuwala*
>>> Software Engineer | WSO2
>>>
>>> Email: gayash...@wso2.com
>>> Phone: +94770548334
>>>
>>> [image: https://wso2.com/signature] <https://wso2.com/signature>
>>>
>>
>>
>> --
>> *Johann Dilantha Nallathamby* | Associate Director/Solutions Architect |
>> WSO2 Inc.
>> (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com
>> [image: Signature.jpg]
>>
>
>
> --
> *Gayashan Bombuwala*
> Software Engineer | WSO2
>
> Email: gayash...@wso2.com
> Phone: +94770548334
>
> [image: https://wso2.com/signature] <https://wso2.com/signature>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>


-- 
Farasath Ahamed
Associate Technical Lead, WSO2 Inc.: http://wso2.com
Mobile: +94777603866
Blog: https://farasath.blogspot.com / https://medium.com/@farasath
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] WSO2 IS - SAML SSO External IdP: handling several AttributeConsumingServiceIndex

2019-10-28 Thread Farasath Ahamed

On Monday, October 28, 2019, Angelo Immediata  wrote:

> Hi all.
>
> I'm using WSO2 Identity Server version 5.8.0 and 5.9.0
>
> I have this scenario: I have external IdPs and I want to allow SAML
> integration with these IdPs. I can register them in WSO2 and all works
> pretty good.
>
> I was facing the following issue: I need to handle several
> AttributeConsumingService. So the first thing I created the WSO2
> ServiceProvider metadata file that I gave to the IdPs. This is the metadata
> content:
>
>> 
>> > ID="_3574ad74-ba7a-4ea5-b3e8-dbb2dafb55df" entityID="http://wso2_590_ai;>
>>> WantAssertionsSigned="true" protocolSupportEnumeration="
>> urn:oasis:names:tc:SAML:2.0:protocol">
>>   
>>  http://www.w3.org/2000/09/xmldsig#;>
>> 
>>
>> 
>>  
>>   
>>   > Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
>> Location="https://localhost:9443/samlsso; />
>>   urn:oasis:names:tc:SAML:2.0:nameid-
>> format:transient
>>   > Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
>> Location="https://localhost:9443/commonauth; index="0" isDefault="true"
>> />
>>   
>>  set0
>>  
>>  > />
>>  > Name="fiscalNumber" />
>>  > Name="email" />
>>  > />
>>   
>>   
>>  set1
>>  
>>  > />
>>  > Name="fiscalNumber" />
>>  > Name="email" />
>>  > />
>>  
>>  > Name="dateOfBirth" />
>>  > Name="placeOfBirth" />
>>   
>>   
>>  set2
>>  
>>  > />
>>  > Name="fiscalNumber" />
>>  > Name="email" />
>>  > />
>>  
>>  > Name="dateOfBirth" />
>>  > Name="placeOfBirth" />
>>  > Name="countyOfBirth" />
>>   
>>   
>>  set3
>>  
>>  > />
>>  > Name="fiscalNumber" />
>>  > Name="email" />
>>  > />
>>  
>>  > Name="dateOfBirth" />
>>  > Name="placeOfBirth" />
>>  > Name="countyOfBirth" />
>>  > Name="mobilePhone" />
>>   
>>   
>>  set4
>>  
>>  > />
>>  > Name="fiscalNumber" />
>>  > />
>>   
>>   
>>  set5
>>  
>>  > />
>>  > Name="fiscalNumber" />
>>  > />
>>  > Name="companyName" />
>>  > Name="registeredOffice" />
>>  > />
>>   
>>
>>
>>   Service provider WSO2
>> 590
>>   WSO2 590> OrganizationDisplayName>
>>   https://localhost:9443/> OrganizationURL>
>>
>> 
>
>
> As you can see I have six AttributeConsumingService. So far so good... the
> problem was how to solve this issue: let's suppose I have a Service
> Provider registered inside WSO2 IS and let's suppose the application
> related to this SP sends in the SAML Request the AttributeConsumingService
> index. How can I pass this AttributeConsumingService to the SAML request
> that WSO2 sends to the external IdPs? I found only one way: to modify the
>>
>> org.wso2.carbon.identity.application.authenticator.samlsso.manager.
>> DefaultSAML2SSOManager.buildAuthnRequest(HttpServletRequest, boolean,
>> String, AuthenticationContext)
>
> method. Just after this instruction
>
>> //Get the inbound SAMLRequest
>> AuthnRequest inboundAuthnRequest = getAuthnRequest(context);
>
>
> I added the following code:
>
>> Integer attrConsServiceIndex = inboundAuthnRequest.
>> getAttributeConsumingServiceIndex();
>> if( attrConsServiceIndex != null && attrConsServiceIndex > 0 ) {
>>if( log.isInfoEnabled() ) {
>> log.info("Inbound SAML Request AttributeConsumingServiceIndex "+
>> attrConsServiceIndex+" Settato nella auth request SAML");
>> }
>> authRequest.setAttributeConsumingServiceIndex(attrConsServiceIndex);
>> }
>
>
> In this way if the Application handled by a Service Provider sends an
> AttributeConsumingServiceIndex different from 0, this is set in the
> AuthnRequest that WSO2 IS builds for the external IdP. I don't know if
> there is a different way to solve it but as far as I investigated this is
> the only solution I found
>
> Is this a proper way?
>
> If so... I hope you can use it and this can be useful to other people.
>
> Thank you
> Angelo
>


-- 
Farasath Ahamed
Associate Technical Lead, WSO2 Inc.: http://wso2.com
Mobile: +94777603866
Blog: https://farasath.blogspot.com / https://medium.com/@farasath
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [IAM] What is the proper way to handle the silent refresh with implicit grant.

2019-10-16 Thread Farasath Ahamed

On Wed, Oct 16, 2019 at 4:36 PM Prakhash Sivakumar 
wrote:

> Hi Devs,
>
> We have an angular application which uses the implicit grant. In the
> application, once the user is authenticated, till the IDP session is active
> we do a silent refresh using an iframe to keep the token alive, but here I
> face a scenario like this.
>
> Let's say the access token is having a lifespan of 10 min and the session
> at the identity server is having a lifespan of 15 min, I would like to do a
> silent refresh when the access token is about to expire. For example in
> like in 9 min. In this case, as there is already an active token exists,
> the IDP will return that active token which is having 1 min lifespan. So
> before the next silent refresh call the token will get expired.
>
> How can I handle this scenario. As this is a SPA, I don't want to do
> revoke and renew because we will have to store the client_secret in order
> to do this. So what is the best approach for this ?
>

Actually, if the token was obtained using the implicit grant, then you
should be able to revoke without the client secret. If the public client is
unable to revoke its token without a client secret, that itself is a
security issue.


>
> I was thinking a scenario like, appending a random scope with original
> requested scope each time we do the silent refresh. So we get a new access
> token every time. Will that be a correct approach ?
>

We can use this approach, if the OAuth2 server does not validate scopes.


>
>
> Appreciate your thoughts on this.
>
> Regards,
> Prakhash
>
> --
> *Prakhash Sivakumar | Senior Software Engineer | WSO2 Inc*
> *+94771510080 | prakh...@wso2.com 
> | https://medium.com/@PrakhashS <https://medium.com/@PrakhashS>*
>


-- 
Farasath Ahamed
Associate Technical Lead, WSO2 Inc.: http://wso2.com
Mobile: +94777603866
Blog: https://farasath.blogspot.com / https://medium.com/@farasath
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [VOTE] Release WSO2 Identity Server 5.9.0 RC2

2019-10-03 Thread Farasath Ahamed

tity Analytics-SSO analyzed via WSO2 IS Analytics.
>>>>>>>- QSG- Self signup, workflow management
>>>>>>>- JIT provision
>>>>>>>- Ask Password
>>>>>>>- Add Email template
>>>>>>>- Connectors- GITHUB, LinkedIn, Google
>>>>>>>- Installing as a Windows Service (Java version- 1.8.0_171)
>>>>>>>- REST APIs for the user portal
>>>>>>>
>>>>>>>Account Recovery - Update challenge questions answers
>>>>>>>
>>>>>>>Authorized OAuth Apps - List and revoke
>>>>>>>
>>>>>>>User session management
>>>>>>>
>>>>>>>Pending Approvals
>>>>>>>
>>>>>>>
>>>>>>> +1 to proceed.
>>>>>>>
>>>>>>> On Wed, Oct 2, 2019 at 4:26 PM Buddhima Udaranga 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> We have tested the Configuration Management REST API with the WSO2
>>>>>>>> IS 5.9.0-RC2 with the MySQL database. No blocker issues found. +1 to
>>>>>>>> proceed.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> *Buddhima Udaranga*|Software Engineer| WSO2 Inc. <http://wso2.com/>
>>>>>>>> (M)+94 714742094 | (E) buddhi...@wso2.com
>>>>>>>> <https://wso2.com/signature>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Oct 2, 2019 at 10:59 AM Piraveena Paralogarajah <
>>>>>>>> pirave...@wso2.com> wrote:
>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> We are pleased to announce the second release candidate of WSO2
>>>>>>>>> Identity Server 5.9.0.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> New Features
>>>>>>>>>
>>>>>>>>>-
>>>>>>>>>
>>>>>>>>>An improved, simpler configuration model
>>>>>>>>>-
>>>>>>>>>
>>>>>>>>>RESTful APIs for user self-services
>>>>>>>>>-
>>>>>>>>>
>>>>>>>>>Passwordless authentication with WebAuthn
>>>>>>>>>-
>>>>>>>>>
>>>>>>>>>Reusable script library for adaptive authentication
>>>>>>>>>-
>>>>>>>>>
>>>>>>>>>Cross-protocol single logout capability
>>>>>>>>>-
>>>>>>>>>
>>>>>>>>>Inbuilt support to view and revoke user sessions
>>>>>>>>>-
>>>>>>>>>
>>>>>>>>>Azure AD/Office365 multi-domain federation support
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Fixes
>>>>>>>>>
>>>>>>>>> This release includes the following issue fixes and improvements:
>>>>>>>>>
>>>>>>>>>-
>>>>>>>>>
>>>>>>>>>5.9.0-m1
>>>>>>>>><https://github.com/wso2/product-is/milestone/85?closed=1>
>>>>>>>>>-
>>>>>>>>>
>>>>>>>>>5.9.0-m2
>>>>>>>>><https://github.com/wso2/product-is/milestone/86?closed=1>
>>>>>>>>>-
>>>>>>>>>
>>>>>>>>>5.9.0-m3
>>>>>>>>><https://github.com/wso2/product-is/milestone/87?closed=1>
>>>>>>>>>-
>>>>>>>>>
>>>>>>>>>5.9.0-m4
>>>>>>>>><https://github.com/wso2/product-is/milestone/88?closed=1>
>>>>>>>>>-
>>>>>>>>>
>>>>>>>>>5.9.0-m5
>>>>>>>>><https://github.com/wso2/product-is/milestone/90?closed=1>
>>>>>>>>>-
>>>>>>>>>
>>>>>>>>>5.9.0-m6
>>>>>>>>><https://github.com/wso2/product-is/milestone/91?closed=1>
>>>>>>>>>-
>>>>>>>>>
>>>>>>>>>5.9.0-alpha
>>>>>>>>><https://github.com/wso2/product-is/milestone/89?closed=1>
>>>>>>>>>-
>>>>>>>>>
>>>>>>>>>5.9.0-beta
>>>>>>>>><https://github.com/wso2/product-is/milestone/93?closed=1>
>>>>>>>>>-
>>>>>>>>>
>>>>>>>>>5.9.0-GA
>>>>>>>>><https://github.com/wso2/product-is/milestone/83?closed=1>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Source and Distribution
>>>>>>>>>
>>>>>>>>> The source and distribution
>>>>>>>>> <https://github.com/wso2/product-is/releases/download/v5.9.0-rc2/wso2is-5.9.0-rc2.zip>
>>>>>>>>> are available at
>>>>>>>>> https://github.com/wso2/product-is/releases/tag/v5.9.0-rc2
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Please download the product, test it, and vote using the following
>>>>>>>>> convention.
>>>>>>>>>
>>>>>>>>> [+] Stable - go ahead and release
>>>>>>>>>
>>>>>>>>> [-] Broken - do not release (explain why)
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> WSO2 Identity and Access Management Team
>>>>>>>>>
>>>>>>>>> *Piraveena Paralogarajah*
>>>>>>>>> Software Engineer | WSO2 Inc.
>>>>>>>>> *(m)* +94776099594 | *(e)* pirave...@wso2.com
>>>>>>>>>
>>>>>>>>> ___
>>>>>>>> Dev mailing list
>>>>>>>> Dev@wso2.org
>>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Niluka Sripali Monnankulama
>>>>>>> Software Engineer - WSO2 Sri Lanka
>>>>>>>
>>>>>>> Mobile : +94 76 76 52843
>>>>>>>
>>>>>>> ___
>>>>>>> Dev mailing list
>>>>>>> Dev@wso2.org
>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> *Mathuriga Thavarajah*
>>>>>> Software Engineer
>>>>>> WSO2 Inc. - http ://wso2.com
>>>>>>
>>>>>> Email : mathur...@wso2.com
>>>>>> Mobile  : +94778191300
>>>>>>
>>>>>>
>>>>>>
>>>>>> *[image: http://wso2.com/signature] <http://wso2.com/signature>*
>>>>>> ___
>>>>>> Dev mailing list
>>>>>> Dev@wso2.org
>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Wijith Bandara
>>>> Software Engineer | WSO2
>>>>
>>>> Email : wij...@wso2.com
>>>> Mobile : +94718970370
>>>> Web : http://wso2.com
>>>>
>>>> <http://wso2.com/signature>
>>>> ___
>>>> Dev mailing list
>>>> Dev@wso2.org
>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>
>>>
>>>
>>> --
>>>
>>> Hasanthi Dissanayake | Associate Technical Lead | WSO2 Inc.
>>> (m) +94718407133 | (w) +94112145345  | Email: hasan...@wso2.com  | Blog:
>>> https://medium.com/@hasanthipurnimadissanayake
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>
>>
>> --
>> Sathya Bandara
>> Senior Software Engineer
>> Blog: https://medium.com/@technospace
>> 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
>>
>
>
> --
> Nilasini Thirunavukkarasu | Senior Software Engineer | WSO2 Inc.
> (m) +94775241823 | Email: nilas...@wso2.com
> <http://wso2.com/signature>
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>


-- 
Farasath Ahamed
Associate Technical Lead, WSO2 Inc.: http://wso2.com
Mobile: +94777603866
Blog: https://farasath.blogspot.com / https://medium.com/@farasath
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Issue with configuring Identity Server is a OIDC provider

2019-09-30 Thread Farasath Ahamed

On Mon, Sep 30, 2019 at 11:23 AM Hasintha Indrajee 
wrote:

>
>
> On Mon, Sep 30, 2019 at 11:17 AM Farasath Ahamed 
> wrote:
>
>>
>>
>> On Fri, Sep 27, 2019 at 5:47 PM Hasintha Indrajee 
>> wrote:
>>
>>> The original problem is we can't execute client authenticators per
>>> application. As per our current implementation we never can have a both
>>> MTLS and Basic Auth client authentication supported in the server while
>>> different clients using Basic auth + MTLS and BasicAuth or MTLS alone.
>>>
>>> Hence I think, the best solution is to make client authenticators
>>> configurable per oauth app. This should be an easy implementation. (Store
>>> engaged authenticators as oauth app property and honour them through an
>>> abstract logic in ClientAuthenticators).
>>>
>> I don't think supporting client authenticators per application would
>> solve this problem either.
>>
>
> Can you please elaborate more on this ?. Simply in this case we can only
> engage Basic client authenticator for this application if we had per
> applications support. Even though mtls is used to enforce extra transport
> level security, it is not required to use certificates derived from mtls
> session to assert client.
>

My point is unless we improve the mutual TLS client authenticator or it's
canHandle() method, we are simply disabling it at the app level instead of
disabling at the server level (by doing the improvement suggested).

If some other app wants to support both (Mutual TLS or basic auth based
client authentication), we will run into this issue again.


>
> @Sathya Bandara  : Is there a spec for MTLS based client
> authentication ? If so we need to read carefully and see whether we need to
> engage mtls authenticator just because of an mtls handshake took place.
> (Don't we need to send an extra header or an attribute asking to
> authenticate client using MTLS session?)
>

+1 to revisit the MLTS based client authentication spec and our
implementation.


>
>>
> What the spec tries to limit is using multiple authentication mechanisms
>> in the *same request*. That does not mean that the application should be
>> limited to one authentication mechanism.
>>
>> Are we suggesting to limit an application to allow only one
>> authentication mechanism?
>>
>>>
>>> However It's rationale to turn this MTLS client authenticator off for OB
>>> since it's one of their OOTB use cases.
>>>
>>> On Fri, Sep 27, 2019 at 5:08 PM Harsha Kumara  wrote:
>>>
>>>> Hi All,
>>>>
>>>> When I configured the IS as KM, same issue occured during the token
>>>> generation as our client initialize using the required keystores. Client
>>>> will set the javax.servlet.request.X509Certificate by default. Our products
>>>> support http verify clent as option which means client can authenticate
>>>> with one or two way SSL. Also there are clients who secure their token
>>>> endpoint with mutual authentication along with the default authentication
>>>> used in the grant types. AFAIK, in OB usecases it require token endpoint to
>>>> secured with MutualTLS. I believe this authenticator should be disabled by
>>>> default. @Hasintha Indrajee  WDYT?
>>>>
>>>> Thanks,
>>>> Harsha
>>>>
>>>> On Sat, Sep 21, 2019 at 10:12 AM Harsha Kumara 
>>>> wrote:
>>>>
>>>>> Thank you for the information. Since I'm using the alpha4 update, it
>>>>> should have that fix. I'll check further
>>>>>
>>>>> On Sat, Sep 21, 2019 at 12:20 AM Sathya Bandara 
>>>>> wrote:
>>>>>
>>>>>> That PR was not merged. Instead the missing registry configs were
>>>>>> re-added [1]
>>>>>>
>>>>>> [1] https://github.com/wso2/product-is/pull/6076
>>>>>>
>>>>>> On Fri, Sep 20, 2019 at 8:35 PM Harsha Kumara 
>>>>>> wrote:
>>>>>>
>>>>>>> Since this either should handle at client side and mandate not to
>>>>>>> send the certificate or we have to disable the handler. Looks like we 
>>>>>>> have
>>>>>>> disabled the handler by default in
>>>>>>> https://github.com/wso2/carbon-identity-framework/pull/2336/files
>>>>>>>
>>>>>>> But I don't see it in the wso2is-5.9.0-alpha4-SNAPSHOT. Was it
>>>>>>> revert again?
>>>

Re: [Dev] Issue with configuring Identity Server is a OIDC provider

2019-09-29 Thread Farasath Ahamed

or.oidc.OpenIDConnectAuthenticator.getOauthResponse(OpenIDConnectAuthenticator.java:615)
>>>>>>>>>>>>>> ~[org.wso2.carbon.identity.application.authenticator.oidc-5.3.2.jar:?]
>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This error occurred due to engaging the
>>>>>>>>>>>>>> MutualTLSAuthenticator in the token exchange flow. Below check 
>>>>>>>>>>>>>> returns list
>>>>>>>>>>>>>> of authenticators greater than one due to engaging this 
>>>>>>>>>>>>>> authenticator. It
>>>>>>>>>>>>>> seems during the token exchange flow, we send the certificate in 
>>>>>>>>>>>>>> the header
>>>>>>>>>>>>>> which lead to trigger the MutualTLSAuthenticator enable checks 
>>>>>>>>>>>>>> and add to
>>>>>>>>>>>>>> the authenticator list. If I removed the mutual authenticator 
>>>>>>>>>>>>>> jar, this
>>>>>>>>>>>>>> started to work.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> // Will return an invalid request response if multiple 
>>>>>>>>>>>>>> authentication mechanisms are engaged irrespective of
>>>>>>>>>>>>>> // whether the grant type is confidential or not.
>>>>>>>>>>>>>> if (oAuthClientAuthnContext.isMultipleAuthenticatorsEngaged()) {
>>>>>>>>>>>>>> tokenRespDTO = handleError(OAuth2ErrorCodes.INVALID_REQUEST, 
>>>>>>>>>>>>>> "The client MUST NOT use more than one " +
>>>>>>>>>>>>>> "authentication method in each", tokenReqDTO);
>>>>>>>>>>>>>> setResponseHeaders(tokReqMsgCtx, tokenRespDTO);
>>>>>>>>>>>>>> triggerPostListeners(tokenReqDTO, tokenRespDTO, 
>>>>>>>>>>>>>> tokReqMsgCtx, isRefreshRequest);
>>>>>>>>>>>>>> return tokenRespDTO;
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Generally people will configure ODIC with external provider
>>>>>>>>>>>>>> and won't encounter this kind of problem. For testing if tried 
>>>>>>>>>>>>>> with our IS
>>>>>>>>>>>>>> as OIDC provider, this will leads to trigger the above error.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Is it required to engage mutual tls authenticator when
>>>>>>>>>>>>>> certificate present? Can't we ship it by default setting to 
>>>>>>>>>>>>>> false?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>> https://docs.wso2.com/display/AM260/Configuring+Single+Sign-on+with+OpenID+Connect
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Harsha
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Harsha Kumara*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Technical Lead, WSO2 Inc.
>>>>>>>>>>>>>> Mobile: +94775505618
>>>>>>>>>>>>>> Email: hars...@wso2.coim
>>>>>>>>>>>>>> Blog: harshcreationz.blogspot.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> GET INTEGRATION AGILE
>>>>>>>>>>>>>> Integration Agility for Digitally Driven Business
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>>
>>>>>>>>>>>>> *Harsha Kumara*
>>>>>>>>>>>>>
>>>>>>>>>>>>> Technical Lead, WSO2 Inc.
>>>>>>>>>>>>> Mobile: +94775505618
>>>>>>>>>>>>> Email: hars...@wso2.coim
>>>>>>>>>>>>> Blog: harshcreationz.blogspot.com
>>>>>>>>>>>>>
>>>>>>>>>>>>> GET INTEGRATION AGILE
>>>>>>>>>>>>> Integration Agility for Digitally Driven Business
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>>
>>>>>>>>>>>> *Harsha Kumara*
>>>>>>>>>>>>
>>>>>>>>>>>> Technical Lead, WSO2 Inc.
>>>>>>>>>>>> Mobile: +94775505618
>>>>>>>>>>>> Email: hars...@wso2.coim
>>>>>>>>>>>> Blog: harshcreationz.blogspot.com
>>>>>>>>>>>>
>>>>>>>>>>>> GET INTEGRATION AGILE
>>>>>>>>>>>> Integration Agility for Digitally Driven Business
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Sathya Bandara
>>>>>>>>>>> Senior Software Engineer
>>>>>>>>>>> Blog: https://medium.com/@technospace
>>>>>>>>>>> WSO2 Inc. http://wso2.com
>>>>>>>>>>> Mobile: (+94) 715 360 421 <+94%2071%20411%205032>
>>>>>>>>>>>
>>>>>>>>>>> <+94%2071%20411%205032>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>
>>>>>>>>>> *Harsha Kumara*
>>>>>>>>>>
>>>>>>>>>> Technical Lead, WSO2 Inc.
>>>>>>>>>> Mobile: +94775505618
>>>>>>>>>> Email: hars...@wso2.coim
>>>>>>>>>> Blog: harshcreationz.blogspot.com
>>>>>>>>>>
>>>>>>>>>> GET INTEGRATION AGILE
>>>>>>>>>> Integration Agility for Digitally Driven Business
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Sathya Bandara
>>>>>>>>> Senior Software Engineer
>>>>>>>>> Blog: https://medium.com/@technospace
>>>>>>>>> WSO2 Inc. http://wso2.com
>>>>>>>>> Mobile: (+94) 715 360 421 <+94%2071%20411%205032>
>>>>>>>>>
>>>>>>>>> <+94%2071%20411%205032>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> *Harsha Kumara*
>>>>>>>>
>>>>>>>> Technical Lead, WSO2 Inc.
>>>>>>>> Mobile: +94775505618
>>>>>>>> Email: hars...@wso2.coim
>>>>>>>> Blog: harshcreationz.blogspot.com
>>>>>>>>
>>>>>>>> GET INTEGRATION AGILE
>>>>>>>> Integration Agility for Digitally Driven Business
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Sathya Bandara
>>>>>>> Senior Software Engineer
>>>>>>> Blog: https://medium.com/@technospace
>>>>>>> WSO2 Inc. http://wso2.com
>>>>>>> Mobile: (+94) 715 360 421 <+94%2071%20411%205032>
>>>>>>>
>>>>>>> <+94%2071%20411%205032>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> *Harsha Kumara*
>>>>>>
>>>>>> Technical Lead, WSO2 Inc.
>>>>>> Mobile: +94775505618
>>>>>> Email: hars...@wso2.coim
>>>>>> Blog: harshcreationz.blogspot.com
>>>>>>
>>>>>> GET INTEGRATION AGILE
>>>>>> Integration Agility for Digitally Driven Business
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> *Harsha Kumara*
>>>>>
>>>>> Technical Lead, WSO2 Inc.
>>>>> Mobile: +94775505618
>>>>> Email: hars...@wso2.coim
>>>>> Blog: harshcreationz.blogspot.com
>>>>>
>>>>> GET INTEGRATION AGILE
>>>>> Integration Agility for Digitally Driven Business
>>>>>
>>>> --
>>>> Sathya Bandara
>>>> Senior Software Engineer
>>>> Blog: https://medium.com/@technospace
>>>> WSO2 Inc. http://wso2.com
>>>> Mobile: (+94) 715 360 421 <+94%2071%20411%205032>
>>>>
>>>> <+94%2071%20411%205032>
>>>>
>>>
>>>
>>> --
>>>
>>> *Harsha Kumara*
>>>
>>> Technical Lead, WSO2 Inc.
>>> Mobile: +94775505618
>>> Email: hars...@wso2.coim
>>> Blog: harshcreationz.blogspot.com
>>>
>>> GET INTEGRATION AGILE
>>> Integration Agility for Digitally Driven Business
>>>
>>
>>
>> --
>>
>> *Harsha Kumara*
>>
>> Technical Lead, WSO2 Inc.
>> Mobile: +94775505618
>> Email: hars...@wso2.coim
>> Blog: harshcreationz.blogspot.com
>>
>> GET INTEGRATION AGILE
>> Integration Agility for Digitally Driven Business
>>
>
>
> --
> Hasintha Indrajee
> WSO2, Inc.
> Mobile:+94 771892453
>
>

-- 
Farasath Ahamed
Associate Technical Lead, WSO2 Inc.: http://wso2.com
Mobile: +94777603866
Blog: https://farasath.blogspot.com / https://medium.com/@farasath
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] WSO2 Committers += Tharindu Bandara

2019-06-04 Thread Farasath Ahamed

Hi All,


It's my pleasure to announce Tharindu Bandara as a WSO2 Committer. He has
been a valuable contributor to the WSO2 team.


In recognition of his contribution, dedication, and commitment he has been
voted as a WSO2 committer.


Congratulations Tharindu and keep up the good work...!



Thanks,

Farasath Ahamed
Associate Technical Lead, WSO2 Inc.: http://wso2.com
Mobile: +94777603866
Blog: https://farasath.blogspot.com / https://medium.com/@farasath
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [VOTE] Release WSO2 Identity Server 5.8.0 RC3

2019-05-22 Thread Farasath Ahamed

/github.com/wso2/product-is/milestone/62?closed=1>
>>>>>- 5.8.0-M3 fixes
>>>>><https://github.com/wso2/product-is/milestone/61?closed=1>
>>>>>- 5.8.0-M2 fixes
>>>>><https://github.com/wso2/product-is/milestone/60?closed=1>
>>>>>- 5.8.0-M1 fixes
>>>>><https://github.com/wso2/product-is/milestone/59?closed=1>
>>>>>
>>>>>
>>>>> Source and distribution
>>>>>
>>>>> Runtime - https://github.com/wso2/product-is/releases/tag/v
>>>>> <https://github.com/wso2/product-is/releases/download/v5.8.0-rc3/wso2is-5.8.0-rc3.zip>
>>>>> 5.8.0-rc3
>>>>> <https://github.com/wso2/product-is/releases/download/v5.8.0-rc3/wso2is-5.8.0-rc3.zip>
>>>>> Analytics -
>>>>> https://github.com/wso2/analytics-is/releases/tag/v5.8.0-rc3
>>>>> <https://github.com/wso2/analytics-is/releases/download/v5.8.0-rc3/wso2is-analytics-5.8.0-rc3.zip>
>>>>>
>>>>>
>>>>> Please download, test the product and vote.
>>>>>
>>>>> [+] Stable - go ahead and release
>>>>> [-] Broken - do not release (explain why)
>>>>>
>>>>>
>>>>> Thanks,
>>>>> - WSO2 Identity and Access Management Team -
>>>>>
>>>>> --
>>>>>
>>>>> Hasanthi Dissanayake
>>>>>
>>>>> Senior Software Engineer | WSO2
>>>>>
>>>>> E: hasan...@wso2.com
>>>>> M :0718407133| http://wso2.com <http://wso2.com/>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Hasanthi Dissanayake
>>>>
>>>> Senior Software Engineer | WSO2
>>>>
>>>> E: hasan...@wso2.com
>>>> M :0718407133| http://wso2.com <http://wso2.com/>
>>>>
>>>
>>>
>>> --
>>> *Shanika Wickramasinghe*
>>> Software Engineer - QA Team
>>>
>>> Email: shani...@wso2.com
>>> Mobile  : +94713503563
>>> Web : http://wso2.com
>>>
>>> <http://wso2.com/signature>
>>>
>>
>>
>> --
>> *Isuranga Perera* | Software Engineer | WSO2 Inc.
>>  +94 71 735 7034 | isura...@wso2.com 
>>
>> ___
>> Architecture mailing list
>> architect...@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>
>
> --
>
> Hasanthi Dissanayake | Senior Software Engineer | WSO2 Inc.
> (m) +94718407133 | (w) +94112145345  | Email: hasan...@wso2.com
>
> ___
> Architecture mailing list
> architect...@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
Farasath Ahamed
Associate Technical Lead, WSO2 Inc.: http://wso2.com
Mobile: +94777603866
Blog: https://farasath.blogspot.com / https://medium.com/@farasath
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] OAuth2 introspection endpoint with token_type_hint parameter

2019-05-10 Thread Farasath Ahamed

Hi,

While supporting *token_type_hint *value access_token and refresh_token is
good, it looks like we need to fix the logic of handling unknown
token_type_hints.

I think Chanaka has raised a valid concern here. If an invalid token hint
is given then we need to do a full search. But it seems that we rely on the
provided token_type_hint to do the search.

@Chanaka Lakmal  Can you create a git issue for this
under product-is repo?


Regards,
Farasath

On Fri, May 10, 2019 at 3:34 PM Nilasini Thirunavukkarasu 
wrote:

> Hi Chanaka,
>
> supporting *token_type_hint *parameter had been fixed in the master
> branch [1][2] and will be released with the upcoming release.
>
> [1] https://github.com/wso2/product-is/issues/3780
> [2]
> https://github.com/wso2-extensions/identity-inbound-auth-oauth/pull/970/files#diff-78ef442733b42d8573912a910e98d884R83
>
> Thanks,
> Nila.
>
> On Fri, May 10, 2019 at 3:09 PM Chanaka Lakmal  wrote:
>
>> Hi all,
>>
>> I encountered an issue when trying to Invoke the OAuth2 Introspection
>> Endpoint of WSO2 IS 5.7.0 as guided by the doc [1]. These are the scenarios
>> I tried a valid token, and a part of the response status:
>>
>>
>>1. Invoke introspection endpoint with the *token. *Response -
>>{"active":true}
>>curl -k -u admin:admin -H 'Content-Type:
>>application/x-www-form-urlencoded' -X POST --data
>>'token=334060588-dd4e-36a5-ad93-440cc77a1cfb'
>>https://localhost:9443/oauth2/introspect
>>
>>2. Invoke introspection endpoint with the *token* and
>>*token_type_hint*=*bearer*. Response - {"active":true}
>>curl -k -u admin:admin -H 'Content-Type:
>>application/x-www-form-urlencoded' -X POST --data
>>'token=334060588-dd4e-36a5-ad93-440cc77a1cfb_type_hint=bearer'
>>https://localhost:9443/oauth2/introspect
>>
>>3. Invoke introspection endpoint with the *token* and
>>*token_type_hint*=*access_token*. Response - {"active":false}
>>curl -k -u admin:admin -H 'Content-Type:
>>application/x-www-form-urlencoded' -X POST --data
>>'token=334060588-dd4e-36a5-ad93-440cc77a1cfb_type_hint=access_token'
>>https://localhost:9443/oauth2/introspect
>>
>>
>> According to the OAuth2 token introspection specification [2],
>>
>> If the server is unable to locate the token using the given hint,
>>
>> it MUST extend its search across all of its supported token types.
>>
>>
>> So, according to the specification, It should send the active parameter
>> of the response as true in the 3rd scenario.
>>
>> Appreciate your thoughts on this.
>>
>> [1]
>> https://docs.wso2.com/display/IS541/Invoke+the+OAuth+Introspection+Endpoint
>> [2] https://tools.ietf.org/html/rfc7662#section-2.1
>>
>> Thanks,
>> Chanaka
>> --
>> *Chanaka Lakmal*  | Software Engineer | WSO2 Inc.
>> Mobile  : (+94) 77 596 2256
>>
>>
>> * <https://wso2.com/signature>*
>>
>
>
> --
> Nilasini Thirunavukkarasu
> Senior Software Engineer - WSO2
>
> Email : nilas...@wso2.com
> Mobile : +94775241823
> Web : http://wso2.com/
>
>
> <http://wso2.com/signature>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>


-- 
Farasath Ahamed
Associate Technical Lead, WSO2 Inc.: http://wso2.com
Mobile: +94777603866
Blog: https://farasath.blogspot.com / https://medium.com/@farasath
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Error when accessing SP after changing TokenPersistenceProcessor in identity.xml

2019-05-08 Thread Farasath Ahamed

Hi Hasini,

AFAIS this is the expected behaviour.

Changing the token processor with existing data is cannot be done unless
you bring the old data to the format understood by the new token processor.

Regards,
Farasath

On Wed, May 8, 2019 at 2:53 PM Hasini Witharana  wrote:

> Hi All,
>
> I created a SP with the below property.
>
> *org.wso2.carbon.identity.oauth.tokenprocessor.PlainTextPersistenceProcessor*
>
> Then I changed the configuration as below and restart the server and
> created another SP.
>
> *org.wso2.carbon.identity.oauth.tokenprocessor.EncryptionDecryptionPersistenceProcessor*
>
> When I try to edit the first SP which was created before the config change
> I got the below error. Is this the expected behaviour?
>
> Caused by: org.wso2.carbon.identity.oauth.IdentityOAuthAdminException:
> Error occurred while processing client id and client secret by
> TokenPersistenceProcessor
> at
> org.wso2.carbon.identity.oauth.dao.OAuthConsumerDAO.getOAuthConsumerSecret(OAuthConsumerDAO.java:87)
> at
> org.wso2.carbon.identity.oauth2.internal.OAuthApplicationMgtListener.getClientSecret(OAuthApplicationMgtListener.java:294)
> at
> org.wso2.carbon.identity.oauth2.internal.OAuthApplicationMgtListener.addClientSecret(OAuthApplicationMgtListener.java:270)
>
> Thank You.
> Hasini
> --
> *Hasini Witharana | **Software Engineer | **WSO2 Inc <https://wso2.com/>*
> *(m) 0766435725 | (w) 0713850143 | (e) hasi...@wso2.com *
>
>

-- 
Farasath Ahamed
Associate Technical Lead, WSO2 Inc.: http://wso2.com
Mobile: +94777603866
Blog: https://farasath.blogspot.com / https://medium.com/@farasath
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Authenticate to provision a user with OAuth with sufficient privileges fails

2019-04-24 Thread Farasath Ahamed

On Thu, Apr 25, 2019 at 7:32 AM Johann Nallathamby  wrote:

> Hi Malithi,
>
> On Thu, Apr 25, 2019 at 12:34 AM Malithi Edirisinghe 
> wrote:
>
>>
>>
>> On Wed, Apr 24, 2019 at 11:13 PM Johann Nallathamby 
>> wrote:
>>
>>> First of all, I don't understand what is the design issue with using
>>> OAuth2 as a handler in authenticating and authorizing access to Rest APIs
>>> by a client? Isn't that what OAuth2 is meant for typically?
>>>
>>
>> Why should an access token just be used to get the authenticated subject,
>> and that is also from introspection where that username is optional
>>
>
> Using the access token to authenticate the client at the resource server
> is one of the design principle behind OAuth2 right?
>

What do we mean by the client here? is it the OAuth client or the end user?
In both cases, there is no *authentication* when the token is presented at
the resource server(In our case resource server is the REST valve and
authorization server is IS), isn't it?

And if the access token was obtained using client_credentials grant flow,
> the authenticated subject would be in fact the application owner in our
> implementation, which is also perfectly fine, because we don't intend to
> bring any other authorization server for this use case. Similarly relying
> on optional 'username' parameter of introspection response, is also
> perfectly fine IMO, because again we never intend to replace our
> authorization server with a 3rd party in this use case.
>

This is not entirely correct.

Since 'username' is optional based on privacy concerns we already have
requests for the possibility of masking the user information from the
introspection response. If we decide to support masking the user
information, then this current design of extracting user information based
on introspection response will break.

Also, we need to think about user consent on sharing claims/attributes in
introspection response too. We do not have this at the moment but we might
need to support it in future. Since the username is optional in
introspection response, it can be returned or not based on user consent.
This would break once again break the current design.


>
>> Why not use the access token for authorization it self. Isn't that how
>> OAuth2 should be used
>>
>
> With regards to authorization, OAuth2 specifies a way for the client to
> request authorization from authorization server and a way to delegate
> authorization to client by the authorization server, via scopes. However,
> how this authorization levels / scopes are interpreted is left to our
> desired implementation. It is the authorization server policy which decides
> what level of authorization the client will get, even if the client doesn't
> request for any scope. So in this use case our authorization server policy
> says, grant the authorization levels to the client based on the
> authorization levels (permissions) of the application owner. This means all
> the applications which are created by same user will inherit the same set
> of permissions from that user. Do you see a problem in assuming this policy?
>
> I haven't thoroughly thought through about the impact of this policy in a
> 3 legged OAuth2 grant flow for the use case of securing product APIs, in
> which case the authenticated subject will be the resource owner, and (s)he
> might have a different set of permissions than the application owner. But
> still I don't think it will create any issues with this policy. Do holler
> if you see any issue there.
>
> Hope I understood your concerns and hope I clarified them.
>
> Thanks & Regards,
> Johann.
>
>
>>
>>>
>>> Secondly, I think if the use case contains secondary user stores and
>>> client expects to call out product APIs like SCIM, it is not wrong to
>>> expect to have the checkbox on for those service providers. I don't see a
>>> big issue in having that expectation really.
>>>
>>> Regards,
>>> Johann.
>>>
>>> On Wed, Apr 24, 2019 at 8:02 PM Malithi Edirisinghe 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Apr 24, 2019 at 4:42 PM Ruwan Abeykoon  wrote:
>>>>
>>>>> Hi All,
>>>>> Is that mean we use the same token to authentication(of the app) and
>>>>> authorization (for the resource), both?
>>>>>
>>>>
>>>> Well actually the case is, we have implemented a mechanism to allow
>>>> access for resources (REST APIs) with an OAuth2 access token.
>>>> Case is, this design is such that the access token is used to retrieve
>>>> the user (from introsp

Re: [Dev] Authenticate to provision a user with OAuth with sufficient privileges fails

2019-04-24 Thread Farasath Ahamed

On Wed, Apr 24, 2019 at 1:23 PM Malithi Edirisinghe 
wrote:

> Hi All,
>
> Yes, the major problem here is using an oauth token to get the user realm
> and using it later for authorization.
> OAuth is for authorization, in that aspect IMO, we need to re-design this
> handler.
>
> However, to come across with present issue with less effort I have below
> suggestion.
> I think if it needs to pick up the user info, it should access the user
> info endpoint with the token and get the realm information from there (user
> store domain, tenant domain) and that info then can be used to authorize
> the user in latter means.
>

So this means only OAuth tokens obtained with "openid" scopes can be used
for authentication at the REST valve right?
Do we have realm information in user info response? IIRC we included realm
information in the id_token only with a recent fix.

Thanks,
> Malithi
>
> On Wed, Apr 24, 2019 at 12:58 PM Isuranga Perera 
> wrote:
>
>> All:
>> With regards $subject[1]
>>
>> Here we have authentication flow and authorization flow. Token validation
>> service is used at authentication and username is set by the validator.
>> However, when "Use user store domain in local subject identifier" is not
>> enabled in Local & Outbound Authentication Configuration usernames of
>> secondary user-store users are set without the domain parameter.
>> Since the user realm is configured depending on the tenant name when
>> authorizing secondary user store users at Authorization Valve suffering
>> from a caching issue which resulted in permission update ignorance.
>> This issue is not affected to tenant users as the tenant is explicitly
>> appended to the username at the time of authentication.
>>
>> $subject can be overcome by enabling "Use user store domain in local
>> subject identifier" in Local & Outbound Authentication Configuration
>>
>>
>> However one of the main issues is OAuth token is used to authenticate the
>> user in AuthenticationValve. We have to reaccess the validity of this
>> design approach as well.
>>
>>
>> Please provide your feedback on the $subject.
>>
>>
>> [1] https://github.com/wso2/product-is/issues/5078
>>
>>
>> Best Regards
>>
>> Isuranga Perera
>>
>> --
>> *Isuranga Perera* | Software Engineer | WSO2 Inc.
>>  +94 71 735 7034 | isura...@wso2.com 
>>
>>
>
> --
>
> *Malithi Edirisinghe*
> Technical Lead
> WSO2 Inc.
>
> Mobile : +94 (0) 718176807
> malit...@wso2.com
>


-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: https://farasath.blogspot.com / https://medium.com/@farasath
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Removing PKCE column check during OAuth data persistence

2019-04-11 Thread Farasath Ahamed

On Thu, Apr 11, 2019 at 3:33 PM Sathya Bandara  wrote:

> Hi all,
>
> Curently in AuthorizationCodeDAOImpl [1] and OAuthAppDAO we have the
> 'isPkceEnabled' flag to check the availability of PKCE columns during data
> persistence. This has been added to handle the migration scenarios. The
> PKCE feature was introduced with IS 5.2.0 and we already have 6 major
> releases after this version addressing the migration aspects. Therefore we
> have decided to remove this column check from the code level with 5.8.0 as
> it becomes redundant.
>
> Please share your thoughts and concerns on this.
>

Big +1


>
> [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/dao/AuthorizationCodeDAOImpl.java#L95
>
> Thanks,
> Sathya
> --
> Sathya Bandara
> Senior Software Engineer
> Blog: https://medium.com/@technospace
> WSO2 Inc. http://wso2.com
> Mobile: (+94) 715 360 421 <+94%2071%20411%205032>
>
> <+94%2071%20411%205032>
>


-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: https://farasath.blogspot.com / https://medium.com/@farasath
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Tenant OIDC logout fails with 'ID token signature validation failed.' error

2019-04-06 Thread Farasath Ahamed

On Friday, April 5, 2019, Sathya Bandara  wrote:

> Hi Farasath,
>
> For federated users, we are setting the SP's tenant domain as user tenant
> domain. However userstore domain will be null. Therefore we can pass only
> the tenant domain in the realm. WDYT?
>
Ok that seems fine.

How are we planning to handle the case where the id_token builder has been
customized?

One possible way is to keep the old logic for customized id_token builders
and id_tokens without "realm" claim.

>
> On Fri, Apr 5, 2019 at 9:36 AM Farasath Ahamed  wrote:
>
>> Hi Devs,
>>
>> Also what about the value of " *realm*" claim when the user is a
>> federated one?
>>
>> Regards,
>> Farasath
>>
>> On Fri, Apr 5, 2019 at 9:32 AM Hasini Witharana  wrote:
>>
>>> Hi Ruwan/Sathya,
>>>
>>> There are some standard claims defined in the OIDC specification[1],
>>> none of them can be used instead of "realm", "tenant_domain".
>>> However, the spec also says that it is okay to add any other claims to
>>> id_token[2].
>>>
>>> [1] - https://openid.net/specs/openid-connect-core-1_0.html#
>>> StandardClaims
>>> [2] - https://openid.net/specs/openid-connect-core-1_0.html#IDToken
>>>
>>> Thank You.
>>> Hasini
>>>
>>> On Fri, Apr 5, 2019 at 6:30 AM Ruwan Abeykoon  wrote:
>>>
>>>> Hi Sathya,
>>>> I do not see any issue adding the info-set to the id-token, as
>>>> conceptually it carries more information about the users identity.
>>>> Did we checked if there an standard claims in id token we could use,
>>>> instead of "realm", "tenant_domain", etc.
>>>>
>>>> Cheers,
>>>> Ruwan A
>>>>
>>>> On Thu, Apr 4, 2019 at 11:43 PM Sathya Bandara  wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> In OIDC logout flow, we send the ID token as a user identification
>>>>> method similar to following request.
>>>>>
>>>>> https://localhost:9443/oidc/logout?id_token_hint=>>>> token>_logout_redirect_uri=http://localhost:8080/
>>>>> playground2/oauth2client=1
>>>>>
>>>>> when validating the ID token, we are trying to get tenant domain from
>>>>> subject claim of the id token hint [1] in the default flow. This will only
>>>>> work if '*append tenant domain to subject identifier'* is selected in
>>>>> the SP configuration. In other scenarios it fails with the error
>>>>> "access_denied ID token signature validation failed." This is because if
>>>>> subject does not contain the tenant domain, we try to validate the id 
>>>>> token
>>>>> with super tenant's keystore. Further this fails when subject identifier 
>>>>> is
>>>>> set as email claim, and email contains a different domain such as
>>>>> sat...@wso2.com 
>>>>>
>>>>> We have a config to enable/disable signing ID token with SP's keystore
>>>>> identity.xml ('SignJWTWithSPKey'). As this configuration is disabled by
>>>>> default, ID token will be signed and validated using user's tenant domain
>>>>> leading to above issue.
>>>>>
>>>>> As a possible solution, we have decided to include user tenant domain
>>>>> and userstore domain as claims in the id token generated by IS. This can 
>>>>> be
>>>>> disabled by a config however in the default pack it will be enabled by
>>>>> default. Sample id token will be as follows.
>>>>>
>>>>> {
>>>>>   "at_hash": "Bi9jGB-EIZ94gVzHZv5trQ",
>>>>>   "aud": "b3F9IGMtm0aKGlHfG4BnI2Ypi7Qa",
>>>>>   "sub": "sathya",
>>>>>
>>>>>
>>>>>
>>>>> *  "realm": {"tenant_domain: "wso2.com <http://wso2.com>",
>>>>> "userstore_domain: "PRIMARY"  }*,
>>>>>   "iss": "https://localhost:9443/oauth2/token;,
>>>>>   "exp": 1554367465,
>>>>>   "iat": 1554363865,
>>>>> }
>>>>>
>>>>> Also 'SignJWTWithSPKey' property will be enabled by default in the
>>>>> product, honoring service provider's tenant domain when obtaining keys for
>>>>>

Re: [Dev] Tenant OIDC logout fails with 'ID token signature validation failed.' error

2019-04-06 Thread Farasath Ahamed

On Friday, April 5, 2019, Sathya Bandara  wrote:

> Hi Farasath,
>
> For federated users, we are setting the SP's tenant domain as user tenant
> domain. However userstore domain will be null. Therefore we can pass only
> the tenant domain in the realm. WDYT?
>
Ok that seems fine.

How are we planning to handle the case where the id_token builder has been
customized?

One possible way is to keep the old logic for customized id_token builders
and id_tokens without "realm" claim.

>
> On Fri, Apr 5, 2019 at 9:36 AM Farasath Ahamed  wrote:
>
>> Hi Devs,
>>
>> Also what about the value of " *realm*" claim when the user is a
>> federated one?
>>
>> Regards,
>> Farasath
>>
>> On Fri, Apr 5, 2019 at 9:32 AM Hasini Witharana  wrote:
>>
>>> Hi Ruwan/Sathya,
>>>
>>> There are some standard claims defined in the OIDC specification[1],
>>> none of them can be used instead of "realm", "tenant_domain".
>>> However, the spec also says that it is okay to add any other claims to
>>> id_token[2].
>>>
>>> [1] - https://openid.net/specs/openid-connect-core-1_0.html#
>>> StandardClaims
>>> [2] - https://openid.net/specs/openid-connect-core-1_0.html#IDToken
>>>
>>> Thank You.
>>> Hasini
>>>
>>> On Fri, Apr 5, 2019 at 6:30 AM Ruwan Abeykoon  wrote:
>>>
>>>> Hi Sathya,
>>>> I do not see any issue adding the info-set to the id-token, as
>>>> conceptually it carries more information about the users identity.
>>>> Did we checked if there an standard claims in id token we could use,
>>>> instead of "realm", "tenant_domain", etc.
>>>>
>>>> Cheers,
>>>> Ruwan A
>>>>
>>>> On Thu, Apr 4, 2019 at 11:43 PM Sathya Bandara  wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> In OIDC logout flow, we send the ID token as a user identification
>>>>> method similar to following request.
>>>>>
>>>>> https://localhost:9443/oidc/logout?id_token_hint=>>>> token>_logout_redirect_uri=http://localhost:8080/
>>>>> playground2/oauth2client=1
>>>>>
>>>>> when validating the ID token, we are trying to get tenant domain from
>>>>> subject claim of the id token hint [1] in the default flow. This will only
>>>>> work if '*append tenant domain to subject identifier'* is selected in
>>>>> the SP configuration. In other scenarios it fails with the error
>>>>> "access_denied ID token signature validation failed." This is because if
>>>>> subject does not contain the tenant domain, we try to validate the id 
>>>>> token
>>>>> with super tenant's keystore. Further this fails when subject identifier 
>>>>> is
>>>>> set as email claim, and email contains a different domain such as
>>>>> sat...@wso2.com 
>>>>>
>>>>> We have a config to enable/disable signing ID token with SP's keystore
>>>>> identity.xml ('SignJWTWithSPKey'). As this configuration is disabled by
>>>>> default, ID token will be signed and validated using user's tenant domain
>>>>> leading to above issue.
>>>>>
>>>>> As a possible solution, we have decided to include user tenant domain
>>>>> and userstore domain as claims in the id token generated by IS. This can 
>>>>> be
>>>>> disabled by a config however in the default pack it will be enabled by
>>>>> default. Sample id token will be as follows.
>>>>>
>>>>> {
>>>>>   "at_hash": "Bi9jGB-EIZ94gVzHZv5trQ",
>>>>>   "aud": "b3F9IGMtm0aKGlHfG4BnI2Ypi7Qa",
>>>>>   "sub": "sathya",
>>>>>
>>>>>
>>>>>
>>>>> *  "realm": {"tenant_domain: "wso2.com <http://wso2.com>",
>>>>> "userstore_domain: "PRIMARY"  }*,
>>>>>   "iss": "https://localhost:9443/oauth2/token;,
>>>>>   "exp": 1554367465,
>>>>>   "iat": 1554363865,
>>>>> }
>>>>>
>>>>> Also 'SignJWTWithSPKey' property will be enabled by default in the
>>>>> product, honoring service provider's tenant domain when obtaining keys for
>>>>>

Re: [Dev] Tenant OIDC logout fails with 'ID token signature validation failed.' error

2019-04-04 Thread Farasath Ahamed

Hi Devs,

Also what about the value of " *realm*" claim when the user is a federated
one?

Regards,
Farasath

On Fri, Apr 5, 2019 at 9:32 AM Hasini Witharana  wrote:

> Hi Ruwan/Sathya,
>
> There are some standard claims defined in the OIDC specification[1], none
> of them can be used instead of "realm", "tenant_domain".
> However, the spec also says that it is okay to add any other claims to
> id_token[2].
>
> [1] - https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims
> [2] - https://openid.net/specs/openid-connect-core-1_0.html#IDToken
>
> Thank You.
> Hasini
>
> On Fri, Apr 5, 2019 at 6:30 AM Ruwan Abeykoon  wrote:
>
>> Hi Sathya,
>> I do not see any issue adding the info-set to the id-token, as
>> conceptually it carries more information about the users identity.
>> Did we checked if there an standard claims in id token we could use,
>> instead of "realm", "tenant_domain", etc.
>>
>> Cheers,
>> Ruwan A
>>
>> On Thu, Apr 4, 2019 at 11:43 PM Sathya Bandara  wrote:
>>
>>> Hi all,
>>>
>>> In OIDC logout flow, we send the ID token as a user identification
>>> method similar to following request.
>>>
>>> https://localhost:9443/oidc/logout?id_token_hint=
>>> _logout_redirect_uri=
>>> http://localhost:8080/playground2/oauth2client=1
>>>
>>> when validating the ID token, we are trying to get tenant domain from
>>> subject claim of the id token hint [1] in the default flow. This will only
>>> work if '*append tenant domain to subject identifier'* is selected in
>>> the SP configuration. In other scenarios it fails with the error
>>> "access_denied ID token signature validation failed." This is because if
>>> subject does not contain the tenant domain, we try to validate the id token
>>> with super tenant's keystore. Further this fails when subject identifier is
>>> set as email claim, and email contains a different domain such as
>>> sat...@wso2.com 
>>>
>>> We have a config to enable/disable signing ID token with SP's keystore
>>> identity.xml ('SignJWTWithSPKey'). As this configuration is disabled by
>>> default, ID token will be signed and validated using user's tenant domain
>>> leading to above issue.
>>>
>>> As a possible solution, we have decided to include user tenant domain
>>> and userstore domain as claims in the id token generated by IS. This can be
>>> disabled by a config however in the default pack it will be enabled by
>>> default. Sample id token will be as follows.
>>>
>>> {
>>>   "at_hash": "Bi9jGB-EIZ94gVzHZv5trQ",
>>>   "aud": "b3F9IGMtm0aKGlHfG4BnI2Ypi7Qa",
>>>   "sub": "sathya",
>>>
>>>
>>>
>>> *  "realm": {"tenant_domain: "wso2.com <http://wso2.com>",
>>> "userstore_domain: "PRIMARY"  }*,
>>>   "iss": "https://localhost:9443/oauth2/token;,
>>>   "exp": 1554367465,
>>>   "iat": 1554363865,
>>> }
>>>
>>> Also 'SignJWTWithSPKey' property will be enabled by default in the
>>> product, honoring service provider's tenant domain when obtaining keys for
>>> signing and validating id tokens.
>>>
>>> Highly appreciate your suggestions and concerns on this.
>>>
>>> [1]
>>> https://github.com/wso2-extensions/identity-inbound-auth-oauth/blob/master/components/org.wso2.carbon.identity.oidc.session/src/main/java/org/wso2/carbon/identity/oidc/session/servlet/OIDCLogoutServlet.java#L331
>>> Thanks,
>>> Sathya
>>> --
>>> Sathya Bandara
>>> Senior Software Engineer
>>> Blog: https://medium.com/@technospace
>>> WSO2 Inc. http://wso2.com
>>> Mobile: (+94) 715 360 421 <+94%2071%20411%205032>
>>>
>>> <+94%2071%20411%205032>
>>>
>>
>>
>> --
>>
>> *Ruwan Abeykoon*
>> *Associate Director/Architect**,*
>> *WSO2, Inc. http://wso2.com <https://wso2.com/signature> *
>> *lean.enterprise.middleware.*
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>
>
> --
> *Hasini Witharana | **Software Engineer | **WSO2 Inc <https://wso2.com/>*
> *(m) 0766435725 | (w) 0713850143 | (e) hasi...@wso2.com *
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>


-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: https://farasath.blogspot.com / https://medium.com/@farasath
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Failed to store SAML assertion when Assertion Query Request profile enabled

2019-03-27 Thread Farasath Ahamed

On Thu, Mar 28, 2019 at 9:24 AM Isuranga Perera  wrote:

> Hi,
>
> Increasing the column size is fine with most databases. However, Oracle
> varchar datatype only allows a maximum of 4000 characters. Because of this
> reason, we will be using an additional column to store the SAML2 assertion
> as a Blob. Existing column will not be modified due to backward
> compatibility reasons.
>

Increasing the column is not an elegant solution since we cannot predict
the size of the SAML assertion. With the number of returned claims, it is
always a gamble :)
Therefore additional column to store the assertion looks good to me.


>
> There are three scenarios that can be affected by this implementation
>
>1. IS 5.8.0 is used along with the modified database schema
>2. IS 5.8.0 is pointed to an old database where
>IDN_SAML2_ASSERTION_STORE table doesn't have this additional column. In
>this case, we will be checking if this additional column exists and act
>accordingly.
>3. User migrate to the new version
>
> Is this the case where we would have both data in the old column
(assertion stored before migration) as well as the new column (assertion
created after migration)?


> Best Regards
> Isuranga Perera
>
> On Tue, Mar 26, 2019 at 12:49 PM Ruwan Abeykoon  wrote:
>
>> Hi Isuranga,
>> There are two easy solutions for this.
>> a) Use compression to store the text field on DB
>> b) Increase the column size
>>
>> Both requires we do not have index for the respective column.
>>
>> Cheers,
>> Ruwan A
>>
>> On Tue, Mar 26, 2019 at 12:45 PM Isuranga Perera 
>> wrote:
>>
>>> Hi All,
>>>
>>> As observed in issue[1] SAML assertion is not persisted in SP-initiated
>>> login as SAML assertion is larger than the column size(4096 in DB2)
>>> specified in the schema. It is not just limited to DB2 as all other DBs has
>>> a similar column size. Since "Assertion query request profile" feature is
>>> already available in IS 5.7.0 this cannot be disabled.
>>>
>>> Appreciate your suggestions on the $subject.
>>>
>>> [1] https://github.com/wso2/product-is/issues/4776
>>>
>>> Best Regards
>>> Isuranga Perera
>>> --
>>> *Isuranga Perera* | Software Engineer | WSO2 Inc.
>>>  +94 71 735 7034 | isura...@wso2.com 
>>>
>>>
>>
>>
>>
>
> --
> *Isuranga Perera* | Software Engineer | WSO2 Inc.
>  +94 71 735 7034 | isura...@wso2.com 
>
>

-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Enable client_id and client_secret based authentication to Introspection endpoint

2019-03-12 Thread Farasath Ahamed

On Tue, Mar 12, 2019 at 7:45 AM Ruwan Abeykoon  wrote:

> Hi Isuranga,
> We can add additional header to make this authenticator engaged. e.g. [1]
>

+1 to use a custom header.


> Better not tie up the authenticator to the hardcoded
> path "INTROSPECTION_URI"
>
>
> [1]
> https://www.ibm.com/support/knowledgecenter/en/SSMNED_2018/com.ibm.apic.apionprem.doc/oauth_introspection.html
>
> Cheers,
> Ruwan
>
>
> On Tue, Mar 12, 2019 at 12:30 PM Isuranga Perera 
> wrote:
>
>> Hi all
>>
>> I'm working on the improvement of client authentication for OAuth2
>> Introspection endpoint[1]. Currently, it supports authentication via basic
>> authentication and bearer token authentication.
>>
>> In this improvement, we're going to introduce authentication via client
>> ID and secret.
>>
>> But the problem with this approach is that both basic authentication and
>> the $subject has the same authorization header. Because of this reason
>> incoming requests have to go through both basic authentication handler and
>> $subject authentication handler which results in additional overhead.
>>
>> The current implementation is as follows[2]. Please provide your insight
>> on the $subject.
>>
>> [1] https://github.com/wso2/product-is/issues/4314
>> [2] https://github.com/wso2-extensions/identity-carbon-auth-rest/pull/67
>>
>> Best Regards
>> Isuranga Perera
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>
>
> --
>
> *Ruwan Abeykoon*
> *Associate Director/Architect**,*
> *WSO2, Inc. http://wso2.com <https://wso2.com/signature> *
> *lean.enterprise.middleware.*
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>


-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Introspection Endpoint improvement to support Client Authentication

2019-02-12 Thread Farasath Ahamed

The GitHub issue title is a bit confusing.

I think it should be to supporting client authentication based on
*client_id* and *client_secret* of the app for the introspection endpoint.

On Tue, Feb 12, 2019 at 7:55 AM Isuranga Perera  wrote:

> Hi Abhishek
>
> In [1] you have mentioned that the client authentication is not enforced
> on oauth2 introspection endpoint. But sample requests given suggests
> otherwise. Can you please clarify what you meant by $subject.
>
> [1] https://github.com/wso2/product-is/issues/4314
>
> Best Regards
> --
> *Isuranga Perera* | Software Engineer | WSO2 Inc.
>  +94 71 735 7034 | isura...@wso2.com 
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>


-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] JWT WSO2

2019-02-07 Thread Farasath Ahamed

On Thu, Feb 7, 2019 at 9:56 PM Felipe Pinheiro <
felipe.pinhe...@ifactory.com.br> wrote:

> Hello,
>
> I am trying to make a change in JWT by adding new information sent in the
> request (/token).
>

So by JWT are you referring to the id_token?

>
> Is there a way to send a parameter in a custom grant type and add that
> parameter inside JWT?
>
> I am with this issue there for some weeks and I don't know if is possible
> to perform that change in the JWT.
>

If you could explain your use case in detail devs will be able to guide on
achieving it using a suitable configuration/extension point.

>
> Thank you very much.
>
> Cheers,
> Felipe Pinheiro
> Software Developer
> [image: telephone] +55 85 996123367 [image: skype] live:felipeagpinheiro 
> [image:
> linkedin] linkedin.com/in/felipe-pinheiro-8b045587
> <https://www.linkedin.com/in/felipe-pinheiro-8b045587/>
> Innovating Commerce with Shopping Intelligence
> [image: OSF Banner]
> <https://www.osf-commerce.com/ifactory-solutions-acquisition>
> https://www.osf-commerce.com/
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>


-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Regarding the dash “-----” Format of Begin of Certificate/ End of Certificate in a PEM file

2019-02-05 Thread Farasath Ahamed

Hi Piraveena,

I tried a few X509 parsers online[1] with  (4 hyphens) in the
delimiter. They seem to work fine.
However, in [2] the cert fingerprint calculation fails if we have 4
hyphens and works fine with 5 hyphens.

I couldn't find any reference strictly stating the requirement on the
number of dashes in the delimiter. However, in most examples online, I saw
5 hyphens used.
So let's use - (5 hyphens) as the delimiter.


[1] http://phpseclib.sourceforge.net/x509/decoder.php
[2] https://www.samltool.com/fingerprint.php


Thanks,
Farasath

On Fri, Feb 1, 2019 at 9:40 AM Piraveena Paralogarajah 
wrote:

> Hi,
>
> I'm working with X509 Authentication and now I need to decode the PEM
> format of X509 Certificate.
>
> I want to know whether the number of dashes in Begin of Certificate/ End
> of Certificate is defined or it depends on the implementation.
>
>  -BEGIN CERTIFICATE-
>
>  -END CERTIFICATE-
>
> Mostly I have seen 5 dashes, but in some places I have different number of
> dashes. For an example, In this Git issue [1], there are 4 dashes. I have
> referred the spec The Internet IP Security PKI Profile of IKEv1/ISAKMP,
> IKEv2, and PKIX  [2] also. Can you please tell whether it is mandatory to
> have 5 dashes in the format?
>
> Any help on this would be appreciated.
>
> [1] https://github.com/wso2/product-is/issues/4352
> [2] https://tools.ietf.org/html/rfc4945#section-6.1
>
> Thanks,
> Piraveena
> *Piraveena Paralogarajah*
> Software Engineer | WSO2 Inc.
> *(m)* +94776099594 | *(e)* pirave...@wso2.com
>
>

-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Authenticating with client_credentials grant failing with due to the use of multiple authenticator execution

2019-01-18 Thread Farasath Ahamed

failing client 
> authentication
> TID: [-1234] [] [2019-01-18 02:51:54,161] DEBUG 
> {org.wso2.carbon.identity.oauth2.client.authentication.OAuthClientAuthnService}
>  -  Setting error to client authentication context : Error code : 
> invalid_request, Error message : The client MUST NOT use more than one 
> authentication method in each
> *TID: [-1234] [] [2019-01-18 02:51:54,184] DEBUG 
> {org.wso2.carbon.identity.oauth2.OAuth2Service} -  Access Token request 
> received for Client ID , User ID null, Scope : [accounts] and 
> Grant Type : client_credentials
> TID: [-1234] [] [2019-01-18 02:51:54,192]  INFO 
> {org.wso2.carbon.identity.oauth.config.OAuthServerConfiguration} -  The 
> default OAuth token issuer will be used. No custom token generator is set.
> TID: [-1234] [] [2019-01-18 02:51:54,192]  INFO 
> {org.wso2.carbon.identity.oauth.config.OAuthServerConfiguration} -  The 
> default Identity OAuth token issuer will be used. No custom token generator 
> is set.
> TID: [-1234] [] [2019-01-18 02:51:54,315] DEBUG 
> {org.wso2.carbon.identity.oauth2.token.AccessTokenIssuer} -  Successfully 
> created AppInfoCache under OAuthCacheManager
> TID: [-1234] [] [2019-01-18 02:51:54,316] DEBUG 
> {org.wso2.carbon.identity.oauth2.token.AccessTokenIssuer} -  Triggering 
> access token pre issuer listeners for client: 
> TID: [-1234] [] [2019-01-18 02:51:54,316] DEBUG 
> {org.wso2.carbon.identity.oauth2.token.AccessTokenIssuer} -  
> OAuth-Error-Code=invalid_request 
> client-id=grant-type=client_credentials scope=accounts
> TID: [-1234] [] [2019-01-18 02:51:54,316] DEBUG 
> {org.wso2.carbon.identity.oauth2.token.AccessTokenIssuer} -  Triggering 
> access token post issuer listeners for client: 
>
> How can I mitigate this behavior? Disable some of the authenticators? set
> priority?
> Please give your input,
>
> Thanks In advance,
> Kaveen Rodrigo
>
> --
> *Kaveen Rodrigo *
> Software Engineer | WS02
>
> Email : kav...@wso2.com
> Mobile : +94779684749
> Web : http://www.wso2.com
>
> <http://goog_953536661>
> [image: http://wso2.com/signature] <http://wso2.com/signature>
>


-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Authenticating with client_credentials grant failing with due to the use of multiple authenticator execution

2019-01-18 Thread Farasath Ahamed

ity.oauth2.client.authentication.OAuthClientAuthnService}
>  -  Setting error to client authentication context : Error code : 
> invalid_request, Error message : The client MUST NOT use more than one 
> authentication method in each
> *TID: [-1234] [] [2019-01-18 02:51:54,184] DEBUG 
> {org.wso2.carbon.identity.oauth2.OAuth2Service} -  Access Token request 
> received for Client ID , User ID null, Scope : [accounts] and 
> Grant Type : client_credentials
> TID: [-1234] [] [2019-01-18 02:51:54,192]  INFO 
> {org.wso2.carbon.identity.oauth.config.OAuthServerConfiguration} -  The 
> default OAuth token issuer will be used. No custom token generator is set.
> TID: [-1234] [] [2019-01-18 02:51:54,192]  INFO 
> {org.wso2.carbon.identity.oauth.config.OAuthServerConfiguration} -  The 
> default Identity OAuth token issuer will be used. No custom token generator 
> is set.
> TID: [-1234] [] [2019-01-18 02:51:54,315] DEBUG 
> {org.wso2.carbon.identity.oauth2.token.AccessTokenIssuer} -  Successfully 
> created AppInfoCache under OAuthCacheManager
> TID: [-1234] [] [2019-01-18 02:51:54,316] DEBUG 
> {org.wso2.carbon.identity.oauth2.token.AccessTokenIssuer} -  Triggering 
> access token pre issuer listeners for client: 
> TID: [-1234] [] [2019-01-18 02:51:54,316] DEBUG 
> {org.wso2.carbon.identity.oauth2.token.AccessTokenIssuer} -  
> OAuth-Error-Code=invalid_request 
> client-id=grant-type=client_credentials scope=accounts
> TID: [-1234] [] [2019-01-18 02:51:54,316] DEBUG 
> {org.wso2.carbon.identity.oauth2.token.AccessTokenIssuer} -  Triggering 
> access token post issuer listeners for client: 
>
> How can I mitigate this behavior? Disable some of the authenticators? set
> priority?
> Please give your input,
>
> Thanks In advance,
> Kaveen Rodrigo
>
> --
> *Kaveen Rodrigo *
> Software Engineer | WS02
>
> Email : kav...@wso2.com
> Mobile : +94779684749
> Web : http://www.wso2.com
>
> <http://goog_953536661>
> [image: http://wso2.com/signature] <http://wso2.com/signature>
>


-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Customizing oauth2 introspection response

2019-01-16 Thread Farasath Ahamed

On Wednesday, January 16, 2019, Nilasini Thirunavukkarasu 
wrote:

> Hi Shiva,
>
> If you want to add a new claim to the token response then you could
> achieve that by following the below steps.
>
>1. Enable AuthorizationContextTokenGeneration as mentioned in [1]
>2. Invoke the introspection endpoint with the required claims (if it
>is more than then it should be comma separated values) similar to below
>request.
>
>curl -k -u admin:admin -H 'Content-Type: application/x-www-form-
>urlencoded' -X POST --data 
> 'token=bff07310-610b-33c1-8d79-95c8c93024e6&*required_claims=http://wso2.org/claims/emailaddress
><http://wso2.org/claims/emailaddress>*' https://localhost:9443/oauth2/
>introspect
>3. Then you will get a JWT with your introspection response. If you
>decode the JWT you could see that the requested claims will be retrieved
>through the JWT.
>
>
> [1] https://docs.wso2.com/display/IS570/JWT+Token+
> Generation#JWTTokenGeneration-Configurations
>
> Thanks,
> Nila.
>
> On Tue, Jan 15, 2019 at 5:41 PM Shiva Kumar K R 
> wrote:
>
>> Hi WSO2 Team,
>> I am using oauth2 token introspection API to verify token status and get
>> user information. Is it possible to customize the response body of this API
>> like adding new claim or modifying existing claim?
>>
>> Thank you,
>> Shiva
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>
>
> --
> Nilasini Thirunavukkarasu
> Software Engineer - WSO2
>
> Email : nilas...@wso2.com
> Mobile : +94775241823
> Web : http://wso2.com/
>
>
> <http://wso2.com/signature>
>


-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Validity of access token after OIDC SLO

2018-11-04 Thread Farasath Ahamed

Hi,

The OIDC spec only specifies how to deal with the authenticated session of
the user (although access token is a part of the response). So in the OIDC
logout, we simply deal with terminating the authenticated session of the
user.

Revoking the token obtained along with OIDC login goes beyond the spec.
Even in our current implementation, this is not something straightforward
since we do not maintain a correlation between the id_token and the issued
access token.

However, we have an extension point introduced with [1] that can be used
for a similar requirement during OIDC logout flow. Something to note is
that even with this extension the correlation between id_token and access
token needs to be handled by the extension developer.

[1] https://github.com/wso2/product-is/issues/3227

Thanks,
Farasath

On Thu, Nov 1, 2018 at 1:58 PM gayan gunawardana 
wrote:

> Hi Devs,
>
> I followed exact instructions in IS 5.7.0 and got logout working. However
> issued access token is valid even after logout (I have checked with token
> introspection). Is that the correct behavior or any justification ?
>
> [1] https://docs.wso2.com/display/IS570/Session+Management+with+Playground
>
> Thanks,
> Gayan
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>

-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [IAM] Deprecating data publishing implementations of identity-data-publisher-authentication

2018-10-07 Thread Farasath Ahamed

Hi,

We could have many extensions written extending the deprecated classes. So
let's make sure this change is captured in migration docs so that any
extension written using the deprecated classes are refactored to use the
newly introduced classes.


Thanks,
Farasath

On Mon, Oct 8, 2018 at 9:46 AM Sachini Wettasinghe 
wrote:

> Hi,
>
> Currently, I am working on a feature to support cross-protocol logout for
> IS. According to the design approach of this project, the data publishing
> implementations are now changed to act as event handlers. For this reason,
> the following classes of identity-data-publisher-authentication component
> are *deprecated* so that they can be removed in a later release.
>
>-
>
> org.wso2.carbon.identity.data.publisher.application.authentication.AbstractAuthenticationDataPublisher
>-
>
> org.wso2.carbon.identity.data.publisher.application.authentication.impl.DASSessionDataPublisherImpl
>-
>
> org.wso2.carbon.identity.data.publisher.application.authentication.impl.AuthenticationAuditLogger
>-
>
> org.wso2.carbon.identity.data.publisher.application.authentication.impl.DASLoginDataPublisherImpl
>
> Regards,
> --
> *Sachini Wettasinghe*
> Software Engineer | WSO2
>
> <http://wso2.com/signature>
>


-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Custom captcha with WSO2 Identity Server

2018-10-04 Thread Farasath Ahamed

On Wed, Oct 3, 2018 at 7:52 PM Jorge  wrote:

> Hi all.
>
> Can I use an offline captcha with WSO2 Identity Server if my servers
> cannot connect to the internet? In the password recovery process I see that
> IS use re-captcha, which requires access to google servers.
>
> Regards,
>Jorge.
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>


-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] WSO2 IS KM 5.6 - XACML Scope Validator

2018-09-11 Thread Farasath Ahamed

Can you check the   section in
KM_HOME/repository/conf/identity/identity.xml of WSO2 IS KM 5.6.0?

It should be as below.





If it is not the case you can change it as above and do a restart.


Thanks,
Farasath

On Tue, Sep 11, 2018 at 4:47 PM, Juan Pablo Vadell 
wrote:

> Hi Devs,
>
> There is a problem when I try to create a Service Provider, access to
> Inbound Authentication Configuration -> OAuth/OpenID Connect Configuration
> -> Configure -> and try to choose *XACML Scope Validator*, because this
> option is not available, I only can see the *Role based scope validator *
> If I try to do the same with the standard distribution of WSO2 IS 5.6,
> XACML Scope Validator appears as an option.
>
> There is a way to do this?
>
> Thank you,
>
> Juan Pablo Vadell | *VATROX*
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] iat, exp and nbf values of token introspection when 'token_string' is a JWT

2018-09-04 Thread Farasath Ahamed

On Wed, Sep 5, 2018 at 11:00 AM, Ruwan Abeykoon  wrote:

> +1 for Ishara's explanation.
>
> We also need to put this in docs clearly.
>

+1. Since 'token_string' is not a standard parameter in the introspection
response we must document it clearly to avoid misinterpretations.


>
> Cheers,
> Ruwan
>
>
> On Wed, Sep 5, 2018 at 9:04 AM Ishara Karunarathna 
> wrote:
>
>> Hi Omindu,
>>
>> Please find my thoughts on this.
>>
>> According to " OAuth 2.0 Token Introspection" specification [1] these
>> value should be based on original access token, And *exp, iat, nbf*
>> values should use the format, defined in the
>> "JSON Web Token (JWT)" specification [2].
>> When we create a JWT out of this, yes there is a confusion. Because [2]
>> JWT spec define these value specific to the new JWT token that we create.
>>
>> Combining these two I interpret in this way.
>> 1. With the *exp, iat, nbf  *in JWT spec define the time frame which
>> this JWT token is valid.
>> 2. All the date in this JWT token is only valid till the original access
>> token is valid.
>> 3. Then the validity of the JWT should be within the validity of original
>> access token.
>>
>> So I think.
>> *iat : *should be the new JWT issuing time.
>> *nbf* : JWT issuing time or original nbf, if this is a future value.
>> *exp* : should be calculated with original exp time.
>>
>> Thanks,
>> Ishara
>>
>> [1] https://tools.ietf.org/html/rfc7662#page-6
>> [2] https://tools.ietf.org/html/rfc7519
>>
>> On Wed, Sep 5, 2018 at 8:17 AM Omindu Rathnaweera 
>> wrote:
>>
>>> Hi Team,
>>>
>>> During token introspection we can request the user information related
>>> to the access token in a form of a JWT. This JWT is sent under the
>>> parameter 'token_string'.
>>>
>>> Ex:
>>>
>>> {
>>>"token_string":"eyJ4NXQiO... (JWT)",
>>>"active":true,
>>>"token_type":"Bearer",
>>>"exp":1536076577,
>>>"iat":1536072977,
>>>"nbf":1536072977,
>>>"client_id":"5qqc07uvtnnouDYzxe63jLlnjOEa",
>>>"username":"admin@carbon.super"
>>> }
>>>
>>> The exp (Expiration Time), iat (Issued At), nbf (Not Before) values in
>>> the above response is based on the original token issue time and this the
>>> expected outcome as per the specification [1].
>>>
>>>
>>> However there's a confusion when it comes to setting these values in the
>>> JWT sent with 'token_string'.
>>>
>>> The current behavior is that 'iat' in the JWT is calculated based on the
>>> issued time of the introspecting access token but the 'exp' value is
>>> calculated based on the creation time of the JWT.
>>>
>>> I would like you know your opinion on what these values should based on.
>>> Should it be same as the access tokens iat, exp, and nbf or should they be
>>> based on the generation time the JWT it self ?
>>>
>>> [1] - https://tools.ietf.org/html/rfc7662#page-6
>>>
>>> Thanks,
>>> Omindu
>>> --
>>> Omindu Rathnaweera
>>> Senior Software Engineer, WSO2 Inc.
>>>
>>
>>
>> --
>> Ishara Karunarathna
>> Technical Lead
>> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>>
>> email: isha...@wso2.com,   blog: isharaaruna.blogspot.com,   mobile:
>> +94717996791
>>
>>
>>
>
> --
>
> *Ruwan Abeykoon*
> *Associate Director/Architect**,*
> *WSO2, Inc. http://wso2.com <https://wso2.com/signature> *
> *lean.enterprise.middleware.*
>
>


-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] APIM : How to integrate google and facebook to APIM via Identity service at the same time?

2018-08-13 Thread Farasath Ahamed

Hi Youcef,

http://xacmlinfo.org/2015/09/01/configure-multiple-federated-identity-providers-with-wso2-identity-server-wso2is/
explains a solution to achieve what you have described.

In Summary, we set a unique identifier for each IDP called the "Home Realm
Identifier". And in the authentication request, we send a query param
called "*fidp*" (eg: fidp=) with the home relam
identifier of the IDP we want the user to redirect to. This would skip the
multi-option page and directly take the user to the IDP.

Thanks,
Farasath

On Fri, Aug 10, 2018 at 12:05 PM, Youcef HILEM 
wrote:

> Hi Sathya,
> All right, that's what I'm looking for.
> Could we associate a service provider with a subscriber to direct it
> directly to the IDP instead of offering a choice between IDPs?
>
> Regargs,
> Youcef
>
>
>
> --
> Sent from: http://wso2-oxygen-tank.10903.n7.nabble.com/WSO2-
> Development-f3.html
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>

-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] IAM: Error while uploading the metadata file in Sp creation.

2018-07-20 Thread Farasath Ahamed

mcat.ext.filter.CharacterSetFilter.doFilte
> r(CharacterSetFilter.java:65)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFi
> lter(ApplicationFilterChain.java:241)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(App
> licationFilterChain.java:208)
> at org.apache.catalina.filters.HttpHeaderSecurityFilter.doFilte
> r(HttpHeaderSecurityFilter.java:124)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFi
> lter(ApplicationFilterChain.java:241)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(App
> licationFilterChain.java:208)
> at org.apache.catalina.core.StandardWrapperValve.invoke(Standar
> dWrapperValve.java:219)
> at org.apache.catalina.core.StandardContextValve.invoke(Standar
> dContextValve.java:110)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHo
> stValve.java:169)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorRepo
> rtValve.java:103)
> at org.wso2.carbon.identity.context.rewrite.valve.TenantContext
> RewriteValve.invoke(TenantContextRewriteValve.java:80)
> at org.wso2.carbon.identity.authz.valve.AuthorizationValve.
> invoke(AuthorizationValve.java:91)
> at org.wso2.carbon.identity.auth.valve.AuthenticationValve.invo
> ke(AuthenticationValve.java:60)
> at org.wso2.carbon.tomcat.ext.valves.CompositeValve.continueInv
> ocation(CompositeValve.java:99)
> at org.wso2.carbon.tomcat.ext.valves.CarbonTomcatValve$1.invoke
> (CarbonTomcatValve.java:47)
> at org.wso2.carbon.webapp.mgt.TenantLazyLoaderValve.invoke(Tena
> ntLazyLoaderValve.java:57)
> at org.wso2.carbon.tomcat.ext.valves.TomcatValveContainer.invok
> eValves(TomcatValveContainer.java:47)
> at org.wso2.carbon.tomcat.ext.valves.CompositeValve.invoke(Comp
> ositeValve.java:62)
> at org.wso2.carbon.tomcat.ext.valves.CarbonStuckThreadDetection
> Valve.invoke(CarbonStuckThreadDetectionValve.java:159)
> at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogVa
> lve.java:962)
> at org.wso2.carbon.tomcat.ext.valves.CarbonContextCreatorValve.
> invoke(CarbonContextCreatorValve.java:57)
> at org.apache.catalina.core.StandardEngineValve.invoke(Standard
> EngineValve.java:116)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAd
> apter.java:445)
> at org.apache.coyote.http11.AbstractHttp11Processor.process(Abs
> tractHttp11Processor.java:1115)
> at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler
> .process(AbstractProtocol.java:637)
> at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun
> (NioEndpoint.java:1775)
> at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(
> NioEndpoint.java:1734)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
> Executor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
> lExecutor.java:624)
> at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.
> run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.wso2.carbon.identity.base.IdentityException: Issuer cannot
> be found in the provided arguments.
> at org.wso2.carbon.identity.core.dao.SAMLSSOServiceProviderDAO.
> addServiceProvider(SAMLSSOServiceProviderDAO.java:216)
> at org.wso2.carbon.identity.core.persistence.IdentityPersistenc
> eManager.addServiceProvider(IdentityPersistenceManager.java:239)
> at org.wso2.carbon.identity.sso.saml.admin.SAMLSSOConfigAdmin.u
> ploadRelyingPartyServiceProvider(SAMLSSOConfigAdmin.java:163)
> ... 73 more
>
>
>
>
> *Thanks & Best Regards!*
>
> *Achini Jayasena*
> *Software Engineer - QA | WSO2*
>
> Email: achi...@wso2.com
> Mobile: +943 882 897
>
> [image: http://wso2.com/signature] <http://wso2.com/signature>
>
> On Mon, Jul 16, 2018 at 10:46 AM, Achini Jayasena 
> wrote:
>
>> Hi All,
>>
>> Scenario: SP creation - metadata configuration.
>>
>> Uploading the metadata file gives following error
>> Error: Metadata uploading failed. Error while uploading the service
>> provider.
>>
>> I use the same metadata file given in the reference [1]. Anybody have
>> idea to sort this out?
>>
>>  [1] Reference: https://docs.wso2.com/display/
>> IS550/Adding+and+Configuring+a+Service+Provider#AddingandCon
>> figuringaServiceProvider-Metadatafileconfiguration
>>
>> Please find the metadata file attached herewith.
>>
>>
>> *Thanks & Best Regards!*
>>
>> *Achini Jayasena*
>> *Software Engineer - QA | WSO2*
>>
>> Email: achi...@wso2.com
>> Mobile: +943 882 897
>>
>> [image: htt

Re: [Dev] UserIdentityManagementAdmin service does not return correct set of challenge questions

2018-07-16 Thread Farasath Ahamed

On Tuesday, July 17, 2018, Rajith Roshan  wrote:

> Hi Devs,
>
> When I add a challenge question to existing challenge set ot create new
> challenge question set from IS 5.3.0 carbon console, and when I invoke the
> "getAllChallengeQuestions" operation in
> UserIdentityManagementAdminService, it  returns the only old set of
> challenge question. The newly added ones are not visible.
>

In our new implementation(from IS 5.3.0), Challenge question related
operations are done using ChallengeQuestionManagementAdminService[1]

[1]
https://github.com/wso2-extensions/identity-governance/blob/master/components/org.wso2.carbon.identity.recovery/src/main/java/org/wso2/carbon/identity/recovery/services/ChallengeQuestionManagementAdminService.java


> And also , when I add a new question using the "setChallengeQuestions" in
> admin service, its get added, and I could not see this newly added question
> in carbon console as well. And also If I invoke the "
> getAllChallengeQuestions" method after adding a challenge question, it
> only shows me the newly added one only.
>
> Your inputs regarding this is highly appreciated.
>
> Thanks!
> Rajith
>
> --
> Rajith Roshan
> Senior Software Engineer, WSO2 Inc.
> Mobile: +94-717-064-214
>


-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] IS 5.5.0 logout gives bellow error

2018-06-29 Thread Farasath Ahamed

0)
> at org.wso2.carbon.tomcat.ext.valves.CompositeValve.continueInv
> ocation(CompositeValve.java:99)
> at org.wso2.carbon.tomcat.ext.valves.CarbonTomcatValve$1.invoke
> (CarbonTomcatValve.java:47)
> at org.wso2.carbon.webapp.mgt.TenantLazyLoaderValve.invoke(Tena
> ntLazyLoaderValve.java:57)
> at org.wso2.carbon.tomcat.ext.valves.TomcatValveContainer.invok
> eValves(TomcatValveContainer.java:47)
> at org.wso2.carbon.tomcat.ext.valves.CompositeValve.invoke(Comp
> ositeValve.java:62)
> at org.wso2.carbon.tomcat.ext.valves.CarbonStuckThreadDetection
> Valve.invoke(CarbonStuckThreadDetectionValve.java:159)
> at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogVa
> lve.java:962)
> at org.wso2.carbon.tomcat.ext.valves.CarbonContextCreatorValve.
> invoke(CarbonContextCreatorValve.java:57)
> at org.apache.catalina.core.StandardEngineValve.invoke(Standard
> EngineValve.java:116)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAd
> apter.java:445)
> at org.apache.coyote.http11.AbstractHttp11Processor.process(Abs
> tractHttp11Processor.java:1115)
> at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler
> .process(AbstractProtocol.java:637)
>
> thanks
>
> *Harsha Thirimanna*
> *Associate Tech Lead | WSO2*
>
> Email: hars...@wso2.com
> Mob: +94715186770
> Blog: http://harshathirimanna.blogspot.com/
> Twitter: http://twitter.com/harshathirimann
> Linked-In: linked-in: http://www.linkedin.com/pub/ha
> rsha-thirimanna/10/ab8/122
> <http://wso2.com/signature>
>



-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] CORS Error

2018-06-15 Thread Farasath Ahamed

On Thu, Jun 14, 2018 at 3:32 PM, shibsankar  wrote:

> *grant_type=password.*
>
>
>
> For your convenience, I  am providing the Angular JS relevant code
>
>
> *// from Angular Controller js*
>
> var dataObj="grant_type=password=x=xxx
> xx=openid";
>
>  Service.callTokenAPI(dataObj)
> .then(function onSuccess(response) {
> console.log("Success");
> console.log("result  = " + JSON.stringify(response));
> }, function onFailure(error) {
> console.log("failure");
> });
>
>
>
> *//from Service.js*
>
> var callTokenAPI = function (dataObj) {
> console.log("Call server dataObj =" + angular.toJson(dataObj));
> var secret=clientKey+":"+clientPass;
> var base64Encoded= btoa(secret);
> console.log("base64Encoded="+base64Encoded);
> return $http({
> url: tokenAPI,
> method: 'POST',
> data: dataObj,
> headers: { "Content-Type": "application/json;charset=utf-8"
> ,"Authorization":base64Encoded}
> });
> };
>
>
Can you try setting the 'content-type' header to
'application/x-www-form-urlencoded'?
(Check [1])

[1]
https://security.stackexchange.com/questions/187311/why-cors-preflight-is-not-available-for-post-requests-when-content-type-is-appli/187312#187312


>
> When I  run this I am getting CORS error screenshot shared earlier.
>
> Regards
> Shib
>
>
> On Thu, Jun 14, 2018 at 3:00 PM, Rushmin Fernando 
> wrote:
>
>> Could you please let us know the grant type you are using here. I would
>> like to know whether this is a valid use case.
>>
>> On Thu, Jun 14, 2018 at 2:54 PM shibsankar  wrote:
>>
>>> Yes.  I get  same CORS error with the correct endpoint, which is */*
>>> *token*
>>>
>>> screenshot attached.
>>>
>>> Regards
>>> Shib
>>>
>>> On Thu, Jun 14, 2018 at 2:42 PM, Rushmin Fernando 
>>> wrote:
>>>
>>>> In the console logs, it says */toekn, *which is wrong spellings.
>>>>
>>>> Do you get the same CORS error with the correct endpoint, which is 
>>>> */**token
>>>> *?
>>>>
>>>> On Thu, Jun 14, 2018 at 2:26 PM shibsankar  wrote:
>>>>
>>>>> I am receiving CORS Error when I call the WSO2 token API  from Angular
>>>>> JS application.
>>>>>
>>>>> How do you fix this?
>>>>>
>>>>> Regards
>>>>> Shib(9831418066)
>>>>>
>>>>>
>>>>> ___
>>>>> Dev mailing list
>>>>> Dev@wso2.org
>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>>
>>>>
>>>>
>>>> --
>>>> *Best Regards*
>>>>
>>>> *Rushmin Fernando*
>>>> *Technical Lead*
>>>>
>>>> WSO2 Inc. <http://wso2.com/> - Lean . Enterprise . Middleware
>>>>
>>>> mobile : +94775615183
>>>>
>>>>
>>>>
>>>
>>
>> --
>> *Best Regards*
>>
>> *Rushmin Fernando*
>> *Technical Lead*
>>
>> WSO2 Inc. <http://wso2.com/> - Lean . Enterprise . Middleware
>>
>> mobile : +94775615183
>>
>>
>>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Will WSO2 IS 5.5.0 support any callback on token revoke.

2018-06-14 Thread Farasath Ahamed

You can use the extension point[1]. Write your own implementation of [1] to
clear the cache at SP on token revocation and register it as an OSGi
service.

[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/oauth/event/
OAuthEventInterceptor.java

Thanks,
Farasath

On Tue, Jun 12, 2018 at 7:34 PM, Shiva Kumar K R 
wrote:

> Hi All,
> I am looking for a callback kind of support in identity server that will
> be called when an access token is revoked.
>
> Background:- I am using identity server for oauth authentication. After
> obtaining the token I will leverage token introspection API to validate
> token on my service provider end. To increase the performance I am caching
> the tokens at SP. When token is revoked how can I clear the cache at the
> SP. Both SP and Identity server use different caches.
>
> Thank you,
> Shiva
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>

-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Replacing existing admin services in WSO2 IS 5.5.0

2018-06-06 Thread Farasath Ahamed

On Tue, Jun 5, 2018 at 3:47 PM, Shiva Kumar 
wrote:

> Hi Farasath,
>
> Thanks for quick response, I can not use the existing revoke service only
> because I will generate oauth2 token from my custom handler which will use
> proxy authentication to validate user and issue the token. In place of
> access token user name will be sent to the revoke endpoint and I will find
> the corresponding token for that user name from Tokenfactory and revoke it.
> Is there any extension point that I can use to get user name from the token
> parameter and replacing it to access token issued to that user name?
>

What is the custom handler? Is it a custom grant handler?

IMO what you are trying to achieve is not suitable to be done by the
Revocation endpoint. Revocation endpoint is meant to be used to revoke a
token a given its identifier. However, in your case you are persisting the
normal access token and sending another value ie. username to identify the
token. So this is not the standard oauth2 revocation usecase.

Could you explan the reason behind sending the username to the revocation
endpoint instead of the actual token that you want to revoke?

>
> On Tuesday 05 June 2018 03:30 PM, Farasath Ahamed wrote:
>
> Rather than customizing the whole OSGi service I would say you should try
> to achieve your use case using an extension point.
> Can you explain the custom logic/custom requirement you are trying to
> inject into the OAuth2 revoke flow?
>
> The reason I am asking this is that there are extension points that get
> triggered during the revoke flow which you may be able to utilize instead
> of trying to customize the default OAuth2Service class.
>
> On Tue, Jun 5, 2018 at 3:26 PM, Shiva Kumar 
> wrote:
>
>> Hi Farashath,
>>
>> Thank you for the reply, I needed customization to /oauth2/revoke
>> endpoint. I observed that /oauth2/revoke endpoint internally using
>> OAuth2Service for token revoking, I thought of extending this class and
>> registering my custom implementation as OSGI service and that endpoint
>> should use my class instead of the existing one. How I could achieve this?
>>
>> On Monday 04 June 2018 11:21 PM, Farasath Ahamed wrote:
>>
>>
>>
>> On Saturday, June 2, 2018, Shiva Kumar  wrote:
>>
>>> Hi,
>>>
>>> I want to replace existing admin service with my custom particularly
>>> OAuthAdminService, How can I do that?
>>
>>
>> You cannot replace admin services that are shipped with the product. You
>> can reuse the code and expose new admin services.
>>
>>  Can you elaborate more on your requirement as to why you need to replace
>> existing admin services?
>>
>>>
>>> Thanks,
>>>
>>> Shiva
>>>
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>
>>
>> --
>> Farasath Ahamed
>> Senior Software Engineer, WSO2 Inc.; http://wso2.com
>> Mobile: +94777603866
>> Blog: blog.farazath.com
>> Twitter: @farazath619 <https://twitter.com/farazath619>
>> <http://wso2.com/signature>
>>
>>
>>
>>
>>
>>
>
>
> --
> Farasath Ahamed
> Senior Software Engineer, WSO2 Inc.; http://wso2.com
> Mobile: +94777603866
> Blog: blog.farazath.com
> Twitter: @farazath619 <https://twitter.com/farazath619>
> <http://wso2.com/signature>
>
>
>
>
>


-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Open ID token expiry duration default value is 0

2018-06-05 Thread Farasath Ahamed

Please create a github issue and lets make sure this gets fixed for IS 5.6.0

On Wednesday, June 6, 2018, Farasath Ahamed  wrote:

> ID Token Expiry time was added to Service Provider level recently as an
> improvement.
>
> We need to validate at the admin service level and set the server level
> default value for id token expiry time if not specified by the user.
>
> We have done similar validations for access token / refresh token expiry
> IIRC. So yes, this needs to be fixed.
>
> On Wednesday, June 6, 2018, Megala Uthayakumar  wrote:
>
>> This was noticed while running test cases, where we create Service
>> Provider through admin service.
>>
>> Thanks.
>>
>> Regards,
>> Megala
>>
>> On Wed, Jun 6, 2018 at 12:11 AM, Megala Uthayakumar 
>> wrote:
>>
>>> Hi,
>>>
>>> I noticed $subject in the latest snapshot pack of IS. If the user does
>>> not specifically configure in service provider level, in the generated ID
>>> token, expiry time claim and issue time claim has the same value and it is
>>> not usable.
>>>
>>> IMHO, it is better to have a default value greater than 0.
>>>
>>> Thanks.
>>>
>>> Regards,
>>> Megala
>>>
>>> --
>>> Megala Uthayakumar
>>>
>>> Senior Software Engineer
>>> Mobile : 0779967122
>>>
>>
>>
>>
>> --
>> Megala Uthayakumar
>>
>> Senior Software Engineer
>> Mobile : 0779967122
>>
>
>
> --
> Farasath Ahamed
> Senior Software Engineer, WSO2 Inc.; http://wso2.com
> Mobile: +94777603866
> Blog: blog.farazath.com
> Twitter: @farazath619 <https://twitter.com/farazath619>
> <http://wso2.com/signature>
>
>
>
>
>

-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Open ID token expiry duration default value is 0

2018-06-05 Thread Farasath Ahamed

ID Token Expiry time was added to Service Provider level recently as an
improvement.

We need to validate at the admin service level and set the server level
default value for id token expiry time if not specified by the user.

We have done similar validations for access token / refresh token expiry
IIRC. So yes, this needs to be fixed.

On Wednesday, June 6, 2018, Megala Uthayakumar  wrote:

> This was noticed while running test cases, where we create Service
> Provider through admin service.
>
> Thanks.
>
> Regards,
> Megala
>
> On Wed, Jun 6, 2018 at 12:11 AM, Megala Uthayakumar 
> wrote:
>
>> Hi,
>>
>> I noticed $subject in the latest snapshot pack of IS. If the user does
>> not specifically configure in service provider level, in the generated ID
>> token, expiry time claim and issue time claim has the same value and it is
>> not usable.
>>
>> IMHO, it is better to have a default value greater than 0.
>>
>> Thanks.
>>
>> Regards,
>> Megala
>>
>> --
>> Megala Uthayakumar
>>
>> Senior Software Engineer
>> Mobile : 0779967122
>>
>
>
>
> --
> Megala Uthayakumar
>
> Senior Software Engineer
> Mobile : 0779967122
>


-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Replacing existing admin services in WSO2 IS 5.5.0

2018-06-05 Thread Farasath Ahamed

Rather than customizing the whole OSGi service I would say you should try
to achieve your use case using an extension point.
Can you explain the custom logic/custom requirement you are trying to
inject into the OAuth2 revoke flow?

The reason I am asking this is that there are extension points that get
triggered during the revoke flow which you may be able to utilize instead
of trying to customize the default OAuth2Service class.

On Tue, Jun 5, 2018 at 3:26 PM, Shiva Kumar 
wrote:

> Hi Farashath,
>
> Thank you for the reply, I needed customization to /oauth2/revoke
> endpoint. I observed that /oauth2/revoke endpoint internally using
> OAuth2Service for token revoking, I thought of extending this class and
> registering my custom implementation as OSGI service and that endpoint
> should use my class instead of the existing one. How I could achieve this?
>
> On Monday 04 June 2018 11:21 PM, Farasath Ahamed wrote:
>
>
>
> On Saturday, June 2, 2018, Shiva Kumar  wrote:
>
>> Hi,
>>
>> I want to replace existing admin service with my custom particularly
>> OAuthAdminService, How can I do that?
>
>
> You cannot replace admin services that are shipped with the product. You
> can reuse the code and expose new admin services.
>
>  Can you elaborate more on your requirement as to why you need to replace
> existing admin services?
>
>>
>> Thanks,
>>
>> Shiva
>>
>>
>> _______
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>
>
> --
> Farasath Ahamed
> Senior Software Engineer, WSO2 Inc.; http://wso2.com
> Mobile: +94777603866
> Blog: blog.farazath.com
> Twitter: @farazath619 <https://twitter.com/farazath619>
> <http://wso2.com/signature>
>
>
>
>
>
>


-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Replacing existing admin services in WSO2 IS 5.5.0

2018-06-04 Thread Farasath Ahamed

On Saturday, June 2, 2018, Shiva Kumar  wrote:

> Hi,
>
> I want to replace existing admin service with my custom particularly
> OAuthAdminService, How can I do that?

You cannot replace admin services that are shipped with the product. You
can reuse the code and expose new admin services.

 Can you elaborate more on your requirement as to why you need to replace
existing admin services?

>
> Thanks,
>
> Shiva
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>

-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Webapps that can be removed for administration node of WSO2IS 5.3.0

2018-06-01 Thread Farasath Ahamed

On Friday, June 1, 2018, Shiva Kumar  wrote:

> Hi All,
>
> I want to deploy WSO2 IS in cluster mode, If I want to have admin console
> to be available in only one node in the cluster, what web apps I should
> remove?

I believe you will be fronting the cluster with a Load Balancer.

Why not send the traffic coming "/carbon" and "/" contexts to a specific
node via LB configs?

This would make sure that whenever someone tries to access the management
console it will be served from the designated node.

>
>
> Thanks,
>
> Shiva
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>

-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] oidc logout fails in is550

2018-04-22 Thread Farasath Ahamed

ve.invoke(
> StandardWrapperValve.java:219)
>
> at org.apache.catalina.core.StandardContextValve.invoke(
> StandardContextValve.java:110)
>
> at org.apache.catalina.core.StandardHostValve.invoke(
> StandardHostValve.java:169)
>
> at org.apache.catalina.valves.ErrorReportValve.invoke(
> ErrorReportValve.java:103)
>
> at org.wso2.carbon.identity.context.rewrite.valve.
> TenantContextRewriteValve.invoke(TenantContextRewriteValve.java:80)
>
> at org.wso2.carbon.identity.authz.valve.AuthorizationValve.invoke(
> AuthorizationValve.java:91)
>
> at org.wso2.carbon.identity.auth.valve.AuthenticationValve.
> invoke(AuthenticationValve.java:60)
>
> at org.wso2.carbon.tomcat.ext.valves.CompositeValve.
> continueInvocation(CompositeValve.java:99)
>
> at org.wso2.carbon.tomcat.ext.valves.CarbonTomcatValve$1.
> invoke(CarbonTomcatValve.java:47)
>
> at org.wso2.carbon.webapp.mgt.TenantLazyLoaderValve.invoke(
> TenantLazyLoaderValve.java:57)
>
> at org.wso2.carbon.tomcat.ext.valves.TomcatValveContainer.
> invokeValves(TomcatValveContainer.java:47)
>
> at org.wso2.carbon.tomcat.ext.valves.CompositeValve.invoke(
> CompositeValve.java:62)
>
> at org.wso2.carbon.tomcat.ext.valves.
> CarbonStuckThreadDetectionValve.invoke(CarbonStuckThreadDetectionValv
> e.java:159)
>
> at org.apache.catalina.valves.AccessLogValve.invoke(
> AccessLogValve.java:962)
>
> at org.wso2.carbon.tomcat.ext.valves.CarbonContextCreatorValve.
> invoke(CarbonContextCreatorValve.java:57)
>
> at org.apache.catalina.core.StandardEngineValve.invoke(
> StandardEngineValve.java:116)
>
> at org.apache.catalina.connector.CoyoteAdapter.service(
> CoyoteAdapter.java:445)
>
> at org.apache.coyote.http11.AbstractHttp11Processor.process(
> AbstractHttp11Processor.java:1115)
>
> at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.
> process(AbstractProtocol.java:637)
>
> at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.
> doRun(NioEndpoint.java:1775)
>
> at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.
> run(NioEndpoint.java:1734)
>
> at java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1149)
>
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:624)
>
> at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(
> TaskThread.java:61)
>
> at java.lang.Thread.run(Thread.java:748)
>
>
>
> *From: *Ciprian Sabolovits <ciprian.sabolov...@cognosante.com>
> *Date: *Friday, April 20, 2018 at 1:26 PM
> *To: *Farasath Ahamed <farasa...@wso2.com>
> *Cc: *WSO2 Developers' List <dev@wso2.org>
> *Subject: *Re: [EXTERNAL SENDER] Re: [Dev] Missing JSESSION cookie
>
>
>
> Currently we get a 500 error when trying to log out the user with a log
> out call.
>
>
>
> https://wso2server/oidc/logout?id_token_hint=ID_TOKEN_HINT
> _logout_redirect_uri=REDIRECT_URI
>
>
>
> 17:20:16 org.wso2.carbon.identity.oidc.session.OIDCSessionManagerException:
> Invalid request. client_id not found in request as parameter.
>
> 17:20:16 at org.wso2.carbon.identity.oidc.session.servlet.
> OIDCSessionIFrameServlet.doGet(OIDCSessionIFrameServlet.java:69)
>
> 17:20:16 at javax.servlet.http.HttpServlet.service(HttpServlet.java:624)
>
> 17:20:16 at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
>
> 17:20:16 at org.eclipse.equinox.http.helper.ContextPathServletAdaptor.
> service(ContextPathServletAdaptor.java:37)
>
> 17:20:16 at org.eclipse.equinox.http.servlet.internal.
> ServletRegistration.service(ServletRegistration.java:61)
>
> 17:20:16 at org.eclipse.equinox.http.servlet.internal.ProxyServlet.
> processAlias(ProxyServlet.java:128)
>
> 17:20:16 at org.eclipse.equinox.http.servlet.internal.ProxyServlet.
> service(ProxyServlet.java:60)
>
> 17:20:16 at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
>
> 17:20:16 at org.wso2.carbon.tomcat.ext.servlet.DelegationServlet.
> service(DelegationServlet.java:68)
>
> 17:20:16 at org.apache.catalina.core.ApplicationFilterChain.
> internalDoFilter(ApplicationFilterChain.java:303)
>
> 17:20:16 at org.apache.catalina.core.ApplicationFilterChain.doFilter(
> ApplicationFilterChain.java:208)
>
> 17:20:16 at org.apache.tomcat.websocket.server.WsFilter.doFilter(
> WsFilter.java:52)
>
> 17:20:16 at org.apache.catalina.core.ApplicationFilterChain.
> internalDoFilter(ApplicationFilterChain.java:241)
>
> 17:20:16 at org.apache.catalina.core.ApplicationFilterChain.doFilter(
> ApplicationFi

Re: [Dev] Missing JSESSION cookie

2018-04-20 Thread Farasath Ahamed

On Fri, Apr 20, 2018 at 12:24 AM, Ciprian Sabolovits <
ciprian.sabolov...@cognosante.com> wrote:

> Hi Everyone,
>
>
>
> Having a problem with WSO2 IS 5.5.0. For some reason IS does not set the
> cookie JSESSIONID and hence the log out functionality with OpenID is
> broken. Any idea why? Do we need to do anything special in configuration to
> get the cookies set?
>

Can you elaborate more on as to why you are relying on the JSESSIONID
cookie for OpenID logout functionality?


>
>
> Thanks,
>
> Ciprian
>
>
> CONFIDENTIALITY NOTICE: This email message and any attachments are for the
> sole use of the intended recipient(s) and may contain confidential
> information of Cognosante Holdings, LLC and/or its subsidiaries, including
> Cognosante, LLC, Cognosante Consulting, LLC, and Cognosante MVH, LLC and is
> protected by law. If you have received this in error, please reply to the
> sender and delete it from your system. If you are the intended recipient,
> you may use the information contained in this message and any files
> attached only as authorized.
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [VOTE] Release WSO2 Identity Server 5.5.0 RC2

2018-03-15 Thread Farasath Ahamed

ps://github.com/wso2/product-is/issues?q=is%3Aclosed+milestone%3A5.5.0-alpha2>
>>>>>>- 5.5.0-Alpha fixes
>>>>>>
>>>>>> <https://github.com/wso2/product-is/issues?q=is%3Aclosed+milestone%3A5.5.0-alpha>
>>>>>>- 5.5.0-M4 fixes
>>>>>>
>>>>>> <https://github.com/wso2/product-is/issues?q=is%3Aclosed+milestone%3A5.5.0-M4>
>>>>>>- 5.5.0-M3 fixes
>>>>>>
>>>>>> <https://github.com/wso2/product-is/issues?q=is%3Aclosed+milestone%3A5.5.0-M3>
>>>>>>- 5.5.0-M2 fixes
>>>>>>
>>>>>> <https://github.com/wso2/product-is/issues?q=is%3Aclosed+milestone%3A5.5.0-M2>
>>>>>>- 5.5.0-M1 fixes
>>>>>>
>>>>>> <https://github.com/wso2/product-is/issues?q=is%3Aclosed+milestone%3A5.5.0-M1>
>>>>>>
>>>>>>
>>>>>> Source and distribution
>>>>>>
>>>>>> Runtime - https://github.com/wso2/product-is/releases/v5.5.0-rc2
>>>>>> Analytics - https://github.com/wso2/anal
>>>>>> ytics-is/releases/v5.5.0-rc2
>>>>>>
>>>>>>
>>>>>> Please download, test the product and vote.
>>>>>>
>>>>>> [+] Stable - go ahead and release
>>>>>> [-] Broken - do not release (explain why)
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> - WSO2 Identity and Access Management Team -
>>>>>>
>>>>>> --
>>>>>> Regards,
>>>>>>
>>>>>>
>>>>>> *Darshana Gunawardana*Technical Lead
>>>>>> WSO2 Inc.; http://wso2.com
>>>>>>
>>>>>> *E-mail: darsh...@wso2.com <darsh...@wso2.com>*
>>>>>> *Mobile: +94718566859 <071%20856%206859>*Lean . Enterprise .
>>>>>> Middleware
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Hasintha Indrajee
>>>>> WSO2, Inc.
>>>>> Mobile:+94 771892453 <+94%2077%20189%202453>
>>>>>
>>>>>
>>>>> ___
>>>>> Architecture mailing list
>>>>> architect...@wso2.org
>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> *Pulasthi Mahawithana*
>>>> Associate Technical Lead
>>>> WSO2 Inc., http://wso2.com/
>>>> Mobile: +94-71-5179022 <+94%2071%20517%209022>
>>>> Blog: https://medium.com/@pulasthi7/
>>>>
>>>> <https://wso2.com/signature>
>>>>
>>>> ___
>>>> Dev mailing list
>>>> Dev@wso2.org
>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>
>>>>
>>>
>>>
>>> --
>>> Ishara Karunarathna
>>> Technical Lead
>>> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>>>
>>> email: isha...@wso2.com,   blog: isharaaruna.blogspot.com,   mobile:
>>> +94717996791 <+94%2071%20799%206791>
>>>
>>>
>>>
>>> ___
>>> Architecture mailing list
>>> architect...@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>> ___
>> Architecture mailing list
>> architect...@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Prakhash Sivakumar
> Senior Software Engineer | WSO2 Inc
> Platform Security Team
> Mobile : +94771510080 <+94%2077%20151%200080>
> Blog : https://medium.com/@PrakhashS
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [VOTE] Release WSO2 Identity Server 5.5.0 RC1

2018-03-14 Thread Farasath Ahamed

Tested Below scenario on the IS 5.5.0-RC1 pack with MSSQL database

   - Create an OAuth app using Dynamic Client Registration endpoint
   - Configured mandatory claims for the service provider
   - Tested OIDC Implicit flow with user consent management enabled
   - Verified that the user claims sent in the id_token are filtered based
   on user consent.

+1 to go ahead and release


On Wed, Mar 14, 2018 at 11:16 AM, Sathya Bandara <sat...@wso2.com> wrote:

> Hi all,
>
> We are pleased to announce the first release candidate of WSO2 Identity
> Server 5.5.0.
>
> This is the first release candidate (RC) of the WSO2 Identity Server 5.5.0
> release.
>
>
> This release fixes the following issues
>
>- 5.5.0-RC1 fixes
>
> <https://github.com/wso2/product-is/issues?q=is%3Aclosed+milestone%3A5.5.0-RC1>
>- 5.5.0-Beta fixes
>
> <https://github.com/wso2/product-is/issues?q=is%3Aclosed+milestone%3A5.5.0-beta>
>- 5.5.0-Alpha3 fixes
>
> <https://github.com/wso2/product-is/issues?q=is%3Aclosed+milestone%3A5.5.0-alpha3>
>- 5.5.0-Alpha2 fixes
>
> <https://github.com/wso2/product-is/issues?q=is%3Aclosed+milestone%3A5.5.0-alpha2>
>- 5.5.0-Alpha fixes
>
> <https://github.com/wso2/product-is/issues?q=is%3Aclosed+milestone%3A5.5.0-alpha>
>- 5.5.0-M4 fixes
>
> <https://github.com/wso2/product-is/issues?q=is%3Aclosed+milestone%3A5.5.0-M4>
>- 5.5.0-M3 fixes
>
> <https://github.com/wso2/product-is/issues?q=is%3Aclosed+milestone%3A5.5.0-M3>
>- 5.5.0-M2 fixes
>
> <https://github.com/wso2/product-is/issues?q=is%3Aclosed+milestone%3A5.5.0-M2>
>- 5.5.0-M1 fixes
>
> <https://github.com/wso2/product-is/issues?q=is%3Aclosed+milestone%3A5.5.0-M1>
>
>
> Source and distribution
>
> Runtime - https://github.com/wso2/product-is/releases/tag/v5.5.0-rc1
> Analytics - https://github.com/wso2/analytics-is/releases/tag/v5.
> 5.0-rc1
>
>
> Please download, test the product and vote.
>
> [+] Stable - go ahead and release
> [-] Broken - do not release (explain why)
>
>
> Thanks,
> - WSO2 Identity and Access Management Team -
>
> --
> Sathya Bandara
> Software Engineer
> WSO2 Inc. http://wso2.com
> Mobile: (+94) 715 360 421 <+94%2071%20411%205032>
>
> <+94%2071%20411%205032>
>



-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Query Regarding the JIRA BUG- IDEBTITY-4250

2018-02-21 Thread Farasath Ahamed

Hi Monika,

A few things to check,

1. Check whether the claims you want in your id_token, user info response
is configured as requested claims (You have already done this)
2. Claim you have defined in #1 have corresponding claim uris in
OIDC(OpenID Connect) dialect.

Some of the claims that are shipped OOTB by WSO2 Identity Server will
already have this mapping (eg: http://wso2.org/claims/givenName has a
corresponding URI in OIDC dialect as *given_name *already)
Basically, you need to have a mapping between the local claim URI and a
claim URI in OIDC dialect (Refer [1])

3. The claim URIs for required claims in OIDC dialect are added to OIDC
scope file. (Refer [2])


[1] https://docs.wso2.com/display/IS530/Adding+Claim+Mapping ("Add an
external claim section")
[2] https://stackoverflow.com/a/40042390/5820670



Thanks,
Farasath


Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>




On Tue, Feb 20, 2018 at 6:26 PM, Chiran Wijesekara <chir...@wso2.com> wrote:

> Hi Monika,
>
> And also make sure that you have done the claim configuration properly. It
> could be found under the given service provider configuration.
>
> Thanks
>
> On Tue, Feb 20, 2018 at 10:35 AM, Sathya Bandara <sat...@wso2.com> wrote:
>
>> Hi Monika,
>>
>> Have you added the required user attributes under user profile section?
>> If these attributes are not provided they will not be available in the user
>> info endpoint response. Please refer [1] for more information.
>>
>> [1] https://docs.wso2.com/display/IS540/Managing+User+Attributes
>>
>> Thanks,
>> Sathya
>>
>> On Tue, Feb 20, 2018 at 10:30 AM, Darshana Gunawardana <darsh...@wso2.com
>> > wrote:
>>
>>> Hi Monika,
>>>
>>> Seems like you haven't subscribed to the dev mailing list properly.. So
>>> the mails you sent to dev getting on hold.. For the moment, i have fwd the
>>> mail to the dev mailing list on your behalf..
>>>
>>> @Sathya: Can you check on this please..
>>>
>>> Thanks,
>>>
>>>
>>> -- Forwarded message --
>>> From: Monika Sharma <monika.sha...@india.nec.com>
>>> Date: Tue, Feb 20, 2018 at 8:29 AM
>>> Subject: RE: Query Regarding the JIRA BUG- IDEBTITY-4250
>>> To: Darshana Gunawardana <darsh...@wso2.com>, WSO2 Developers' List <
>>> dev@wso2.org>
>>>
>>>
>>> Hello sir ,
>>>
>>>
>>>
>>> Thank you so much for giving your valuable time. I have tried by adding
>>> requested claims in the SP.
>>>
>>> I have added the following request claims in the SP :
>>>
>>>
>>>
>>> 1.   http://wso2.org/claims/userid
>>>
>>> 2.   http://wso2.org/claims/created
>>>
>>> 3.   http://wso2.org/claims/country
>>>
>>> 4.   http://wso2.org/claims/displayName
>>>
>>> 5.   http://wso2.org/claims/emailaddres
>>>
>>> 6.   http://wso2.org/claims/givenName
>>>
>>> 7.   http://wso2.org/claims/groups
>>>
>>>
>>>
>>> And subject claim URI is:
>>>
>>> 1.   http://wso2.org/claims/emailaddres
>>>
>>>
>>>
>>> Now response is as below:
>>>
>>>
>>>
>>> {
>>>
>>> "sub”: admin",
>>>
>>> "give_name" : "admin",
>>>
>>>   "email" : "ad...@wso2.com"
>>>
>>> }
>>>
>>>
>>>
>>> Only few information is displayed. Please let me know is it expected
>>> result ?
>>>
>>>
>>>
>>> Thanks & Regards
>>>
>>> Monika Sharma
>>>
>>>
>>>
>>>
>>>
>>> *From:* Darshana Gunawardana [mailto:darsh...@wso2.com]
>>> *Sent:* Saturday, February 17, 2018 10:13 PM
>>> *To:* Monika Sharma; WSO2 Developers' List
>>> *Subject:* Re: Query Regarding the JIRA BUG- IDEBTITY-4250
>>>
>>>
>>>
>>> Hi Monika,
>>>
>>>
>>>
>>> Have you added requested claims in the SP claim configurations section?
>>> If you haven't added any requested claims, returning only the subject from
>>> the userinfo endpoint is expected..
>>>
>>>
>>>
>>> Try adding requested claims in the SP.
&g

Re: [Dev] Support for encrypted ID tokens in OIDC

2018-02-09 Thread Farasath Ahamed

On Friday, February 9, 2018, Vihanga Liyanage <viha...@wso2.com> wrote:

> [- Engineering, Strategy]
> [+ Architecture, Dev]
>
> Thanks,
> Vihanga
>
> On Fri, Feb 9, 2018 at 8:56 AM, Vihanga Liyanage <viha...@wso2.com> wrote:
>
>> Hi Farasath,
>>
>> For the above two points IMO it would be better to provide an option at
>>> Service Provider OAuth/OIDC configuration. This will be similar to what we
>>> have done for SAML.
>>>
>>
>> That is the initial idea came to me as well. But shouldn't the clients
>> have a choice of deciding that as well? May be through a request parameter.
>> To use either JWS or JWE, the client have to support them right?
>>
>
By enabling the option to encrypt id_token in the service provider configs
the client is acknowledging that it can support encrypted id_tokens.

AFAIK even for JWE we need to first sign and then encrypt. Also I couldn't
find any reference on a standard approach to allow clients to switch
between JWS and JWE via a request parameter.

If we take a look at how we handle this is SAML, we have an option in the
SAML configs to say whether the assertion needs to be encrypted or not.
Once the option to encrypt assertion is enabled SAML assertions will always
be encrypted for the particular service provider (ie. There is no
requirement to switch between signed or encrypted assertions)

IMO we can follow the same approach. WDYT?


>>> On a separate note, any specific reason why we are discussing this in
>>> strategy and not in Dev and architecture mailing lists?
>>>
>>> I feel that we need to discuss this feature in architecture mailing list
>>> to get the input from community.
>>>
>>
>> No such specific reason at all. On the previous project I did, the mail
>> was asked to sent to engineering and strategy. So I followed the same
>> protocol. I'll change that now.
>>
>>>
>>>
>>>>
>>>> Thanks,
>>>> Vihanga.
>>>>
>>>> --
>>>>
>>>> Vihanga Liyanage
>>>>
>>>> Software Engineer | WS*O₂* Inc.
>>>>
>>>> M : +*94710124103* | http://wso2.com
>>>>
>>>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>>>>
>>>>
>>>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=icon>
>>>>  Virus-free.
>>>> www.avast.com
>>>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=link>
>>>> <#m_-4836321406318245336_m_-5520087002137875506_m_-4545884336410447238_m_682166417964237_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>>>
>>>> --
>>>> 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.
>>>>
>>>
>>>
>>> --
>>> Farasath Ahamed
>>> Senior Software Engineer, WSO2 Inc.; http://wso2.com
>>> Mobile: +94777603866
>>> Blog: blog.farazath.com
>>> Twitter: @farazath619 <https://twitter.com/farazath619>
>>> <http://wso2.com/signature>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>>
>> Vihanga Liyanage
>>
>> Software Engineer | WS*O₂* Inc.
>>
>> M : +*94710124103* | http://wso2.com
>>
>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>>
>
>
>
> --
>
> Vihanga Liyanage
>
> Software Engineer | WS*O₂* Inc.
>
> M : +*94710124103* | http://wso2.com
>
> [image: http://wso2.com/signature] <http://wso2.com/signature>
>


-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] User with an authenticated session is not prompted for login after SP configuration change

2018-01-19 Thread Farasath Ahamed

On Friday, January 19, 2018, Sathya Bandara <sat...@wso2.com> wrote:

> Hi all,
>
> When there is an already authenticated session for an application user
> with Identity Server, there is no necessity to prompt for another login to
> the IS if the user logs into the application from another tab in the same
> browser.
> However we can change the service providers authentication scheme
> (authentication steps and authenticators in each step) while the user has
> this session.
> In this case, if the user tries to log into the application he is not
> prompted for re-authentication. This is the default behavior of IS.
> Shouldn't we prompt the user to authenticate if the service provider's
> authentication scheme is modified or is this an intended behavior?
>
> Appreciate your thoughts on this.
>

The reason for this behaviour is that we cache the service provider
configuration in the users session context(context created for successful
authentication ). This session context is stored against the cookie
(commonauth) used to identify whether the user already has a session in IS.

So whenever a user reauthenticates user's authenticated steps/idps are
compared with cached service proivder configs.

When you change the service provider configs it does not get reflected in
the cached service provider configs in the user's authenticated session.

With the current implementation this is the expected behaviour.

But IMO we should improve this to always fetch the latest service provider
configs and compare user's authentication steps/IDPs against it. (ie. We
should avoid caching configurations)

Shall we create a github issue to track this improvement?

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

-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] Updating the permission tree programatically

2018-01-10 Thread Farasath Ahamed

Hi Devs,

I have a requirement to implement $subject. I was able to find blog post[1]
which explain how to achieve this using registry APIs.

I also came across a discussion[2] in which a clean API to add/manage
custom permissions is suggested. But looks like this has not been completed.

Can we consider having an API as suggested in [2]?


[1]
http://shazninazeer.blogspot.com/2014/10/adding-new-permissions-to-permission.html
[2]
http://wso2-oxygen-tank.10903.n7.nabble.com/Adding-custom-permissions-progametically-td78468.html


Thanks,
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Problem with extracting a value in a SOAP response through a shell script

2018-01-07 Thread Farasath Ahamed

On Sunday, January 7, 2018, Rushmin Fernando <rush...@wso2.com> wrote:

> IMO we can ask to install xmllint as a pre-requisite.
>

I too think its fine to install xmllint as a pre-requisite. Otherwise we
are overcomplicating our QSG impl by going for complex and error prone
alternatives rather than doing it in a straight forward manner using
xmllint.

>
>
> Using a regular expression to extract the values from an XML might be
> error prone since the regular expression is vulnerable to spaces or lines
> breaks which can be added in future releases.
>
> But xmllint is a proper XML parser. So it will work as long the schema is
> the same.
>
>
>

> On Sat, Jan 6, 2018 at 8:48 PM, Gayan Gunawardana <ga...@wso2.com> wrote:
>
>> Please check below approach if it works for your requirement.
>>
>> cmd=$(curl -k -H "Authorization: Basic YWRtaW46YWRtaW4=" -H
>> "Content-Type: text/xml;charset=UTF-8" -H "SOAPAction:urn:getApplication"
>> -d @get_sp.xml "https://$IP_ADDRESS:$HTTPS_PO
>> RT_IS/services/IdentityApplicationManagementService?wsdl")
>> cp /dev/null get_sp_reponse.xml
>> echo $cmd >> get_sp_reponse.xml
>> applicationID=$(grep -oP '(?<=ax2199:applicationID>)[^<]+'
>> "get_sp_reponse.xml")
>> echo "Service Provider Application ID: $applicationID"
>>
>> *get_sp.xml*
>>
>> http://schemas.
>> xmlsoap.org/soap/envelope/" xmlns:xsd="http://org.apache.axis2/xsd;>
>>
>>
>>   
>>  
>>  SERVICE_PROVIDER_NAME
>>   
>>
>> 
>>
>> On Fri, Jan 5, 2018 at 5:08 PM, Nipuni Bhagya <nipu...@wso2.com> wrote:
>>
>>> Hi all,
>>>
>>> I'm writing shell scripts for the IAM Quick Start Guide and currently,
>>> I'm working on the shell script which automates the configuration of SSO
>>> with SAML2. I have encountered a problem while trying to get the
>>> application Id of a service provider in order to perform an update
>>> operation.
>>>
>>> The method I'm using to overcome this at the moment is,
>>>
>>> 1. I call the getApplication function in the Identity Application
>>> Management API
>>> 2. Write the response to a text file.
>>> 3. Convert that text file into an XML file.
>>> 4. grep the value of 
>>>
>>> But the problem with this approach is that I'm using a tool called xmllint 
>>> to
>>> convert the text to XML format. Since xmllint is not a default Unix command
>>> the users will have to install it on their machines first. As it is not
>>> appropriate to ask for the user's password while running a script, I can't
>>> use xmllint and also most of the other approaches available.
>>>
>>> So I would really appreciate if someone of you could help me to find a
>>> better way to achieve this task.
>>>
>>> Thank you in advance,
>>> --
>>>
>>>
>>>
>>> *Kind Regards,Nipuni Bhagya*
>>>
>>> *Software Engineering Intern*
>>> *WSO2*
>>>
>>>
>>>
>>> *Mobile : +94 0779028904 <+94%2077%20767%201807>*
>>>
>>
>>
>>
>> --
>> Gayan Gunawardana
>> Senior Software Engineer; WSO2 Inc.; http://wso2.com/
>> Email: ga...@wso2.com
>> Mobile: +94 (71) 8020933
>>
>
>
>
> --
> *Best Regards*
>
> *Rushmin Fernando*
> *Technical Lead*
>
> WSO2 Inc. <http://wso2.com/> - Lean . Enterprise . Middleware
>
> mobile : +94775615183
>
>
>

-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Configuring IWA on Linux

2017-12-18 Thread Farasath Ahamed

Can you try the same command from Powershell?

On Monday, December 18, 2017, Chalitha Waldeniyage <chali...@wso2.com>
wrote:

> Hi Farasath,
>
> This was the output of the command prompt.  cmd is ran as the
> administrator. (attached a screenshot as well)
>
>
> *'setspn' is not recognized as an internal or external command,operable
> program or batch file*
>
> *.*
>
>
>
>
> On Mon, Dec 18, 2017 at 7:49 PM, Farasath Ahamed <farasa...@wso2.com>
> wrote:
>
>> Hi,
>>
>> What was the output when you tried to register the SPN?
>>
>>
>> On Monday, December 18, 2017, Chalitha Waldeniyage <chali...@wso2.com>
>> wrote:
>>
>>> Hi All,
>>>
>>> I'm trying to configure kerberos server (AD)  in order to configure IWA
>>> on linux. As per the instruction in [1] [2], I have tried the steps and
>>> under step 6, it's required to register WSO2 IS as a service principal in
>>> Active Directory. But when i try to execute these commands as below, those
>>> commands are not recognized and execution didn't happen. I have followed
>>> all the steps in [2] in order to resolve this. but still it's not helping.
>>> Any idea how to resolve this ?
>>>
>>>
>>>
>>> *Commands:*setspn -A HTTP/windows-2012-ad.wso2.test is_linux
>>> setspn -A HTTP/windows-2012-ad is_linux
>>>
>>>
>>>
>>> *AD domain*
>>> wso2.test
>>>
>>> *DNS host mapping*
>>> Windows-2012-ad.wso2.test
>>>
>>>
>>> *Windows version*
>>> Windows 2012 R2
>>>
>>>
>>> [1] https://docs.wso2.com/display/IS540/Configuring+IWA+on+Linux
>>>
>>> [2] https://medium.com/@farasath/integrated-windows-authenticati
>>> on-with-kerberos-and-wso2-identity-server-ffcd8263a0f1
>>>
>>> [2] https://technet.microsoft.com/en-us/library/ff646952(v=ws.10).aspx
>>>
>>>
>>> Thank you,
>>> Chalitha.
>>> --
>>> *Chalitha Maheshwari*
>>> Software Engineer-QA,
>>> WSO2 Inc.
>>>
>>> *E-mail:* chali...@wso2.com
>>> *Mobile: *+94710 411 112 <+94%2071%20041%201112>
>>>
>>
>>
>> --
>> Farasath Ahamed
>> Senior Software Engineer, WSO2 Inc.; http://wso2.com
>> Mobile: +94777603866
>> Blog: blog.farazath.com
>> Twitter: @farazath619 <https://twitter.com/farazath619>
>> <http://wso2.com/signature>
>>
>>
>>
>>
>>
>
>
> --
> *Chalitha Maheshwari*
> Software Engineer-QA,
> WSO2 Inc.
>
> *E-mail:* chali...@wso2.com
> *Mobile: *+94710 411 112
>


-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Configuring IWA on Linux

2017-12-18 Thread Farasath Ahamed

Hi,

What was the output when you tried to register the SPN?

On Monday, December 18, 2017, Chalitha Waldeniyage <chali...@wso2.com>
wrote:

> Hi All,
>
> I'm trying to configure kerberos server (AD)  in order to configure IWA on
> linux. As per the instruction in [1] [2], I have tried the steps and under
> step 6, it's required to register WSO2 IS as a service principal in Active
> Directory. But when i try to execute these commands as below, those
> commands are not recognized and execution didn't happen. I have followed
> all the steps in [2] in order to resolve this. but still it's not helping.
> Any idea how to resolve this ?
>
>
>
> *Commands:*setspn -A HTTP/windows-2012-ad.wso2.test is_linux
> setspn -A HTTP/windows-2012-ad is_linux
>
>
>
> *AD domain*
> wso2.test
>
> *DNS host mapping*
> Windows-2012-ad.wso2.test
>
>
> *Windows version*
> Windows 2012 R2
>
>
> [1] https://docs.wso2.com/display/IS540/Configuring+IWA+on+Linux
>
> [2] https://medium.com/@farasath/integrated-windows-
> authentication-with-kerberos-and-wso2-identity-server-ffcd8263a0f1
>
> [2] https://technet.microsoft.com/en-us/library/ff646952(v=ws.10).aspx
>
>
> Thank you,
> Chalitha.
> --
> *Chalitha Maheshwari*
> Software Engineer-QA,
> WSO2 Inc.
>
> *E-mail:* chali...@wso2.com
> *Mobile: *+94710 411 112
>


-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Login to Identity Server using another Identity Server - OAuth2

2017-12-15 Thread Farasath Ahamed

On Friday, December 15, 2017, Sherene Mahanama <sher...@wso2.com> wrote:

> Hi Nilasini/Isuru
>
> AFAIU, the doc jira states that we have to create an SP in each instance
> of IS and that the doc bug is that we have missed mentioning the SP created
> in IS1 (playground sample).
>
> In doc [1], we have said to create an SP for IS2 (9444) in step 2 and in
> step 5 we have said to set up the playground sample in IS1 (9443). To set
> up the playground sample, we have pointed to this doc [2] which instructs
> the user to create an SP. So if the user follows the steps, he/she will end
> up creating an SP in each instance.
>
> However, I guess this can be made a bit more clearer in the doc. Will look
> into that.
>

Adding a small diagram would make things much clear IMO 

>
> [1] https://docs.wso2.com/display/IS540/Login+to+
> Identity+Server+using+another+Identity+Server+-+OAuth2
> [2] https://docs.wso2.com/display/IS540/Setting+Up+the+Sample+Webapp
>
> Thanks,
> Sherene
>
> On Fri, Dec 15, 2017 at 3:14 PM, Shavindri Dissanayake <shavin...@wso2.com
> > wrote:
>
>> Ack for docs! We will look into this. There were a few doc JIRAs created
>> over the week for this scenario (OAuth and SAML2 both).
>>
>> Thanks & Regards
>> Shavindri Dissanayake
>> Senior Technical Writer
>>
>> WSO2 Inc.
>> lean.enterprise.middleware
>>
>> On Fri, Dec 15, 2017 at 3:03 PM, Isuru Uyanage <isur...@wso2.com> wrote:
>>
>>> Hi Nilasini/Hasanthi,
>>> Thank you for the clarification.
>>>
>>>
>>> Thanks,
>>> Isuru
>>>
>>> *Thanks and Best Regards,*
>>>
>>> *Isuru Uyanage*
>>> *Software Engineer - QA | WSO2*
>>> *Mobile : **+94 77 <+94%2077%20767%201807> 55 30752*
>>> *LinkedIn: **https://www.linkedin.com/in/isuru-uyanage/
>>> <https://www.linkedin.com/in/isuru-uyanage/>*
>>>
>>>
>>>
>>>
>>> On Fri, Dec 15, 2017 at 2:26 PM, Nilasini Thirunavukkarasu <
>>> nilas...@wso2.com> wrote:
>>>
>>>> Created a documentation jira[1] to track this.
>>>>
>>>>
>>>> [1] https://wso2.org/jira/browse/DOCUMENTATION-7409
>>>>
>>>> On Fri, Dec 15, 2017 at 2:07 PM, Nilasini Thirunavukkarasu <
>>>> nilas...@wso2.com> wrote:
>>>>
>>>>> Hi Isuru,
>>>>>
>>>>> Actual steps must be.
>>>>>
>>>>> 1) create a sp(sp name:-sample)  in second one(9444)
>>>>> 2) create a sp(spname:- playground) in the first one(9443)
>>>>> 3) create an IDP in the first one(9443) by giving the second one(9444)
>>>>> authorization endpoint and etc as mentioned in the doc. Also fill the
>>>>> client_id & secret from the second one's(9444) SP you got by the step 1.
>>>>>
>>>>>
>>>>> Documentation is only mention about one service provider. We need to
>>>>> correct it. I will create a doc jira for that
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Nila.
>>>>>
>>>>>
>>>>> On Fri, Dec 15, 2017 at 1:23 PM, Isuru Uyanage <isur...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> I'm trying to login to Identity Server using another Identity Server.
>>>>>> I followed doc[1].
>>>>>> It has been asked to follow the below steps.
>>>>>>
>>>>>>- Configure an IDP(Idp9443) in Identity Server1.
>>>>>>- Configure an SP(SP9444) in Identity Server2.
>>>>>>- In the second Identity Server, in Service Provider
>>>>>>Configuration, select Idp9443, which is created in first IS, as the
>>>>>>federated authenticator in Local and Outbound Authentication 
>>>>>> Configuration.
>>>>>>
>>>>>>
>>>>>> My question is it only displays the IDPs created in its own Identity
>>>>>> Server in Service Provider/Outbound Authentication Configuration. We
>>>>>> created the IDP in IS1. How is it going to be displayed in Federated
>>>>>> Authenticators in IS2?
>>>>>>
>>>>>> It would be highly appreciated if these steps can be verified and
>>>>>> specify if I have missed any configuration step here.
>>>>>>
>>>>>

Re: [Dev] [IS] [OAuth] Cannot be generated an authorization code using an active access token for "OAuthRequestPathAuthenticator"

2017-12-14 Thread Farasath Ahamed

On Friday, December 15, 2017, Kavitha Subramaniyam <kavi...@wso2.com> wrote:

> Hi Farasath,
>
> Yes, it is working [1] with skipping the consent, Thanks!
>  I hope this is a workaround and it needs to be fixed [2]?
>

This is not a workaround. Infact its the expected behaviour. If it is not
documented we need to do so. RequestPath authentication will only skip the
login page and not the consent page.


>  BTW I don't understand why the authentication not accepted the consent
> value which sent in authorize request as I tried on above reply. Please
> advice on this.
>

Can you check how this works in a normal authentiction flow?

I mean when you click on Approve in the consent screen AFAIR we post a
reply with the sessionDataKey.

Btw is the approach you are trying (send consent as a query param)
documented anywhere?


>
> [1]
> < Location: https://curl-app/callback?code=e07765b9-d27f-30d8-b63d-
> 63fe6e131fb6_state=a52d2de9ca4a6702b532c91df1356d
> 9f02f048db88f641ae5f80531ab2e35c04.J9WOprGoq9RVx2VYXR5-1Q
>
> [2] [https://wso2.org/jira/browse/IDENTITY-7154]
>
> On Fri, Dec 15, 2017 at 11:55 AM, Kavitha Subramaniyam <kavi...@wso2.com>
> wrote:
>
>> Hi Farasath,
>> Ok I will try with skipping consent and let you know the result.
>> Between I have tried requesting the code with appending the consent value
>> (consent=approve) in the request and it was given same response as above.
>> Any idea why the same behaviour?
>>
>> Thanks,
>>
>> On Fri, Dec 15, 2017 at 11:30 AM, Farasath Ahamed <farasa...@wso2.com>
>> wrote:
>>
>>> Please ignore my previous reply.
>>>
>>> This look like the consent screen (the 302 you got in the response)
>>> which requires user interaction to either approve or deny. Can you try
>>> skipping consent using identity.xml configuration[1] and retry the scenario?
>>>
>>> [1] https://docs.wso2.com/plugins/servlet/mobile?contentId=6
>>> 0493981#content/view/60493981
>>> (Refer last Note)
>>>
>>> On Friday, December 15, 2017, Kavitha Subramaniyam <kavi...@wso2.com>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I have tried "oauth-bearer" Request path authentication scenario. In
>>>> case I need to generate an authorization code using an active access token
>>>> which should be recieved from the response.
>>>> Steps I followed are as per doc [1]:
>>>>
>>>>- Register a SP
>>>>- Configure OAuth/ OIDC with enbling password/code/refresh grant
>>>>types
>>>>- Configure "OAuthRequestPathAuthenticator" in local and outbound
>>>>authenticator section
>>>>- Generate access token using password type => recieved a valid
>>>>token
>>>>- Request for code using above token => Expected behaviour is to
>>>>recieve auth code in the response "Location" header. But I didn't see 
>>>> the
>>>>code in the response  as per [2]
>>>>
>>>> Raised a jira for this in [3]. Appreciate any insight on this please.
>>>>
>>>> [1] https://docs.wso2.com/display/IS540/OAuth+Request+Path+Authe
>>>> nticator
>>>> [3] https://wso2.org/jira/browse/IDENTITY-7154
>>>> [2]
>>>>
>>>> > POST /oauth2/authorize HTTP/1.1
>>>> > Host: localhost:9444
>>>> > User-Agent: curl/7.43.0
>>>> > Accept: */*
>>>> > Authorization: Bearer 86c1f0ab-831e-3ae1-9a82-93a55a49bcdb
>>>> > Content-Type: application/x-www-form-urlencoded;charset=UTF-8
>>>> > Content-Length: 109
>>>> >
>>>> * upload completely sent off: 109 out of 109 bytes
>>>> < HTTP/1.1 302 Found
>>>> < X-Frame-Options: DENY
>>>> < X-Content-Type-Options: nosniff
>>>> < X-XSS-Protection: 1; mode=block
>>>> < Set-Cookie: commonAuthId=f8ace6c7-da84-4d0f-b3c6-4ae6ca40ac64; Path=/; 
>>>> Secure; HttpOnly
>>>> < Date: Tue, 12 Dec 2017 12:48:31 GMT
>>>> < Location: 
>>>> https://localhost:9444/authenticationendpoint/oauth2_consent.do?loggedInUser=admin=NewOauthSP=openid=fd18c0f9-0151-420a-8389-49b955705722=<
>>>>  Content-Length: 0
>>>> < Server: WSO2 Carbon Server
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> --
>>>> Kavitha.S
>>>> *Software Engineer -QA*
>>>> email : kavi...@wso2.com
>>>> Mobile : +94 (0) 771538811 <%2B94%20%280%29%20773%20451194>
>>>>
>>>>
>>>
>>> --
>>> Farasath Ahamed
>>> Senior Software Engineer, WSO2 Inc.; http://wso2.com
>>> Mobile: +94777603866
>>> Blog: blog.farazath.com
>>> Twitter: @farazath619 <https://twitter.com/farazath619>
>>> <http://wso2.com/signature>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Kavitha.S
>> *Software Engineer -QA*
>> email : kavi...@wso2.com
>> Mobile : +94 (0) 771538811 <%2B94%20%280%29%20773%20451194>
>>
>>
>
>
> --
> Kavitha.S
> *Software Engineer -QA*
> email : kavi...@wso2.com
> Mobile : +94 (0) 771538811 <%2B94%20%280%29%20773%20451194>
>
>

-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [IS] [OAuth] Cannot be generated an authorization code using an active access token for "OAuthRequestPathAuthenticator"

2017-12-14 Thread Farasath Ahamed

Please ignore my previous reply.

This look like the consent screen (the 302 you got in the response) which
requires user interaction to either approve or deny. Can you try skipping
consent using identity.xml configuration[1] and retry the scenario?

[1]
https://docs.wso2.com/plugins/servlet/mobile?contentId=60493981#content/view/60493981
(Refer last Note)

On Friday, December 15, 2017, Kavitha Subramaniyam <kavi...@wso2.com> wrote:

> Hi all,
>
> I have tried "oauth-bearer" Request path authentication scenario. In case
> I need to generate an authorization code using an active access token which
> should be recieved from the response.
> Steps I followed are as per doc [1]:
>
>- Register a SP
>- Configure OAuth/ OIDC with enbling password/code/refresh grant types
>- Configure "OAuthRequestPathAuthenticator" in local and outbound
>authenticator section
>- Generate access token using password type => recieved a valid token
>- Request for code using above token => Expected behaviour is to
>recieve auth code in the response "Location" header. But I didn't see the
>code in the response  as per [2]
>
> Raised a jira for this in [3]. Appreciate any insight on this please.
>
> [1] https://docs.wso2.com/display/IS540/OAuth+Request+Path+Authenticator
> [3] https://wso2.org/jira/browse/IDENTITY-7154
> [2]
>
> > POST /oauth2/authorize HTTP/1.1
> > Host: localhost:9444
> > User-Agent: curl/7.43.0
> > Accept: */*
> > Authorization: Bearer 86c1f0ab-831e-3ae1-9a82-93a55a49bcdb
> > Content-Type: application/x-www-form-urlencoded;charset=UTF-8
> > Content-Length: 109
> >
> * upload completely sent off: 109 out of 109 bytes
> < HTTP/1.1 302 Found
> < X-Frame-Options: DENY
> < X-Content-Type-Options: nosniff
> < X-XSS-Protection: 1; mode=block
> < Set-Cookie: commonAuthId=f8ace6c7-da84-4d0f-b3c6-4ae6ca40ac64; Path=/; 
> Secure; HttpOnly
> < Date: Tue, 12 Dec 2017 12:48:31 GMT
> < Location: 
> https://localhost:9444/authenticationendpoint/oauth2_consent.do?loggedInUser=admin=NewOauthSP=openid=fd18c0f9-0151-420a-8389-49b955705722=<
>  Content-Length: 0
> < Server: WSO2 Carbon Server
>
>
>
> Thanks,
>
> --
> Kavitha.S
> *Software Engineer -QA*
> email : kavi...@wso2.com
> Mobile : +94 (0) 771538811 <%2B94%20%280%29%20773%20451194>
>
>

-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [IS] [OAuth] Cannot be generated an authorization code using an active access token for "OAuthRequestPathAuthenticator"

2017-12-14 Thread Farasath Ahamed

Have you engaged the request path authenticator for the service provider
under Local and Outbound authentication configuration section?

Can we have a screenshot of the SP local and outbound auth section
(including request path authentication) section to see whether request path
authentication is engaged?

On Friday, December 15, 2017, Kavitha Subramaniyam <kavi...@wso2.com> wrote:

> Hi all,
>
> I have tried "oauth-bearer" Request path authentication scenario. In case
> I need to generate an authorization code using an active access token which
> should be recieved from the response.
> Steps I followed are as per doc [1]:
>
>- Register a SP
>- Configure OAuth/ OIDC with enbling password/code/refresh grant types
>- Configure "OAuthRequestPathAuthenticator" in local and outbound
>authenticator section
>- Generate access token using password type => recieved a valid token
>- Request for code using above token => Expected behaviour is to
>recieve auth code in the response "Location" header. But I didn't see the
>code in the response  as per [2]
>
> Raised a jira for this in [3]. Appreciate any insight on this please.
>
> [1] https://docs.wso2.com/display/IS540/OAuth+Request+Path+Authenticator
> [3] https://wso2.org/jira/browse/IDENTITY-7154
> [2]
>
> > POST /oauth2/authorize HTTP/1.1
> > Host: localhost:9444
> > User-Agent: curl/7.43.0
> > Accept: */*
> > Authorization: Bearer 86c1f0ab-831e-3ae1-9a82-93a55a49bcdb
> > Content-Type: application/x-www-form-urlencoded;charset=UTF-8
> > Content-Length: 109
> >
> * upload completely sent off: 109 out of 109 bytes
> < HTTP/1.1 302 Found
> < X-Frame-Options: DENY
> < X-Content-Type-Options: nosniff
> < X-XSS-Protection: 1; mode=block
> < Set-Cookie: commonAuthId=f8ace6c7-da84-4d0f-b3c6-4ae6ca40ac64; Path=/; 
> Secure; HttpOnly
> < Date: Tue, 12 Dec 2017 12:48:31 GMT
> < Location: 
> https://localhost:9444/authenticationendpoint/oauth2_consent.do?loggedInUser=admin=NewOauthSP=openid=fd18c0f9-0151-420a-8389-49b955705722=<
>  Content-Length: 0
> < Server: WSO2 Carbon Server
>
>
>
> Thanks,
>
> --
> Kavitha.S
> *Software Engineer -QA*
> email : kavi...@wso2.com
> Mobile : +94 (0) 771538811 <%2B94%20%280%29%20773%20451194>
>
>

-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] SP-SAML & Idp-OIDC

2017-12-11 Thread Farasath Ahamed

Token URL and Authorization URL are not pointing to LinkedIn endpoints.
Seems like thats the issue.

Can you change the token and authorization endpoint urls to linkedIn
specific values anf retry the scenario?

On Monday, December 11, 2017, Isuru Uyanage <isur...@wso2.com> wrote:

> Hi All,
>
> I'm trying to implement scenario 11 in the doc[1]. I followed following
> steps.
>
>- Configured Google as the Service Provider(SAML)
>- Configured LinkedIn as the external Identity Provider(Open ID
>Connect) - refer the configuration in the attached image ->
>LinkedInConfig.png
>- Google SP's Authentication Type is set to Federated Authentication -
>LinkedIn.
>
> Once I tried to log in to *mail.google.com <http://mail.google.com>* with
> the relavant email address, it does not redirect me to LinkedIn.Instead, it
> gives the following error in the Browser.
>
> {"error_description":"A valid OAuth client could not be found for
> client_id: 126217798160084","error":"invalid_client"}
>
> I tried the same scenario by configuring Facebook as the Identity Provider
> using OIDC. I got the same abouve result.
> Once these are configured through the relevant connectors, they work well.
>
> Any thoughts on this issue are highly appreciated.
>
>
> [1] - https://medium.facilelogin.com/thirty-solution-patterns-
> with-the-wso2-identity-server-16f9fd0c0389
>
> *Thanks and Best Regards,*
>
> *Isuru Uyanage*
> *Software Engineer - QA | WSO2*
> *Mobile : **+94 77 <+94%2077%20767%201807> 55 30752*
> *LinkedIn: **https://www.linkedin.com/in/isuru-uyanage/
> <https://www.linkedin.com/in/isuru-uyanage/>*
>
>
>
>

-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [ Dev] Error whileproduct-apim build

2017-12-11 Thread Farasath Ahamed

Looking at logs the actual exception seems to be,

[INFO] INFO  
[org.wso2.carbon.automation.extensions.servers.utils.ServerLogReader]
- Caused by: java.lang.NullPointerException
[INFO] INFO  
[org.wso2.carbon.automation.extensions.servers.utils.ServerLogReader]
-   at 
org.wso2.carbon.user.core.util.UserCoreUtil.addDomainToName(UserCoreUtil.java:536)
[INFO] INFO  
[org.wso2.carbon.automation.extensions.servers.utils.ServerLogReader]
-   at 
org.wso2.carbon.user.core.common.AbstractUserStoreManager.getRoleListOfUser(AbstractUserStoreManager.java:2728)


On Saturday, December 9, 2017, Ishara Cooray  wrote:

> I have observed *Error occurred while accessing Java Security Manager
> Privilege Block* [3] in product-apim build.
>
> java version = jdk 1.8.0_45
> kernel 4.4.16
>
> But this seem to have fixed in kernel 4.4.8 as[1]
>
> Also there is a similar issue reported in [2] which is still in open state.
>
> *@Identity Team/Platform Team,*
>
> Appreciate if you can look into this as this is a blocker for apim 2.1.0
> -update 2 release
>
> [1] https://wso2.org/jira/browse/IDENTITY-5991
> [2] https://wso2.org/jira/browse/IDENTITY-5110
> [3]
>
> [INFO] INFO  
> [org.wso2.carbon.automation.extensions.servers.utils.ServerLogReader] - 
> [2017-12-08 18:01:25,541] ERROR - AbstractUserStoreManager Error occurred 
> while accessing Java Security Manager Privilege Block
> [INFO] INFO  
> [org.wso2.carbon.automation.extensions.servers.utils.ServerLogReader] - 
> [2017-12-08 18:01:25,542] ERROR - ContentBasedSearchService Invalid Search 
> Query, query contains invalid characters
> [INFO] INFO  
> [org.wso2.carbon.automation.extensions.servers.utils.ServerLogReader] - 
> org.apache.solr.common.SolrException: Error while creating user role filter 
> query
> [INFO] INFO  
> [org.wso2.carbon.automation.extensions.servers.utils.ServerLogReader] -  at 
> org.wso2.carbon.registry.indexing.solr.SolrClient.addUserRoleFilter(SolrClient.java:752)
> [INFO] INFO  
> [org.wso2.carbon.automation.extensions.servers.utils.ServerLogReader] -  at 
> org.wso2.carbon.registry.indexing.solr.SolrClient.query(SolrClient.java:598)
> [INFO] INFO  
> [org.wso2.carbon.automation.extensions.servers.utils.ServerLogReader] -  at 
> org.wso2.carbon.registry.indexing.solr.SolrClient.query(SolrClient.java:545)
> [INFO] INFO  
> [org.wso2.carbon.automation.extensions.servers.utils.ServerLogReader] -  at 
> org.wso2.carbon.registry.indexing.service.ContentBasedSearchService.searchContentInternal(ContentBasedSearchService.java:166)
> [INFO] INFO  
> [org.wso2.carbon.automation.extensions.servers.utils.ServerLogReader] -  at 
> org.wso2.carbon.registry.indexing.service.ContentBasedSearchService.searchByAttribute(ContentBasedSearchService.java:279)
> [INFO] INFO  
> [org.wso2.carbon.automation.extensions.servers.utils.ServerLogReader] -  at 
> org.wso2.carbon.registry.indexing.internal.IndexingServiceComponent$AttributeSearchServiceImpl.search(IndexingServiceComponent.java:161)
> [INFO] INFO  
> [org.wso2.carbon.automation.extensions.servers.utils.ServerLogReader] -  at 
> org.wso2.carbon.registry.indexing.internal.IndexingServiceComponent$AttributeSearchServiceImpl.search(IndexingServiceComponent.java:174)
> [INFO] INFO  
> [org.wso2.carbon.automation.extensions.servers.utils.ServerLogReader] -  at 
> org.wso2.carbon.registry.indexing.internal.IndexingServiceComponent$AttributeSearchServiceImpl.search(IndexingServiceComponent.java:188)
> [INFO] INFO  
> [org.wso2.carbon.automation.extensions.servers.utils.ServerLogReader] -  at 
> org.wso2.carbon.registry.indexing.internal.IndexingServiceComponent$AttributeSearchServiceImpl.search(IndexingServiceComponent.java:155)
> [INFO] INFO  
> [org.wso2.carbon.automation.extensions.servers.utils.ServerLogReader] -  at 
> org.wso2.carbon.governance.lcm.util.CommonUtil.isLifecycleNameInUse(CommonUtil.java:576)
> [INFO] INFO  
> [org.wso2.carbon.automation.extensions.servers.utils.ServerLogReader] -  at 
> org.wso2.carbon.governance.lcm.util.CommonUtil.addLifecycle(CommonUtil.java:262)
> [INFO] INFO  
> [org.wso2.carbon.automation.extensions.servers.utils.ServerLogReader] -  at 
> org.wso2.carbon.governance.lcm.util.CommonUtil.addDefaultLifecyclesIfNotAvailable(CommonUtil.java:496)
> [INFO] INFO  
> [org.wso2.carbon.automation.extensions.servers.utils.ServerLogReader] -  at 
> org.wso2.carbon.apimgt.hostobjects.APIProviderHostObject.jsFunction_login(APIProviderHostObject.java:266)
> [INFO] INFO  
> [org.wso2.carbon.automation.extensions.servers.utils.ServerLogReader] -  at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [INFO] INFO  
> [org.wso2.carbon.automation.extensions.servers.utils.ServerLogReader] -  at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [INFO] INFO  
> [org.wso2.carbon.automation.extensions.servers.utils.ServerLogReader] -  at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [INFO]

Re: [Dev] WSO2 Identity Server 5.4.0 Alpha 9 Released !!!

2017-11-22 Thread Farasath Ahamed

Hi Tharindu,

I downloaded the alpha9 tag
https://github.com/wso2/product-is/tree/v5.4.0-alpha9 and built it skipping
the tests without any problem.

*Java version*
java version "1.8.0_144"
Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)

*Maven Version*
Apache Maven 3.0.5
Maven home: /usr/share/maven
Java version: 1.8.0_144, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-oracle/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.13.0-113-generic", arch: "amd64", family:
"unix"


Could this be due to maven/java version difference?

Farasath Ahamed
Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>



On Thu, Nov 23, 2017 at 12:10 PM, Tharindu Edirisinghe <tharin...@wso2.com>
wrote:

> Hi Devs,
>
> I tried to build the IS 5.4.0 alpha9 and when I build the v5.4.0-alpha9
> tag in product-is skipping the tests, I got the following error.
>
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 1.215 s
> [INFO] Finished at: 2017-11-23T11:33:53+05:30
> [INFO] Final Memory: 45M/1237M
> [INFO] 
> 
> [ERROR] Failed to execute goal org.apache.maven.plugins:
> maven-remote-resources-plugin:1.5:process (default) on project
> identity-server-parent: Error finding remote resources manifests:
> /home/tharindu/Desktop/alpha9/product-is/target/maven-
> shared-archive-resources/META-INF/NOTICE (No such file or directory) ->
> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-remote-resources-plugin:1.5:process
> (default) on project identity-server-parent: Error finding remote resources
> manifests
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(
> MojoExecutor.java:212)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(
> MojoExecutor.java:153)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(
> MojoExecutor.java:145)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.
> buildProject(LifecycleModuleBuilder.java:116)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.
> buildProject(LifecycleModuleBuilder.java:80)
> at org.apache.maven.lifecycle.internal.builder.singlethreaded.
> SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.
> execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.codehaus.plexus.classworlds.launcher.Launcher.
> launchEnhanced(Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.
> launch(Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.
> mainWithExitCode(Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.
> main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error finding
> remote resources manifests
> at org.apache.maven.plugin.resources.remote.
> ProcessRemoteResourcesMojo.processResourceBundles(
> ProcessRemoteResourcesMojo.java:1238)
> at org.apache.maven.plugin.resources.remote.
> ProcessRemoteResourcesMojo.execute(ProcessRemoteResourcesMojo.java:520)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(
> DefaultBuildPluginManager.java:134)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(
> MojoExecutor.java:207)
> ... 20 more
> Caused by: java.io.FileNotFoundException: 
> /home/tharindu/Desktop/alpha9/*product-is/target/maven-shared-archive-resources/META-INF/NOTICE
> (No such file or directory)*
> at java.io.FileOutputStream.open0(Native

Re: [Dev] Self Contained Access Tokens in IS 5.4.0

2017-11-17 Thread Farasath Ahamed

Farasath Ahamed
Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>



On Fri, Nov 17, 2017 at 6:48 PM, Johann Nallathamby <joh...@wso2.com> wrote:

>
>
> On Fri, Nov 17, 2017 at 6:39 PM, Malithi Edirisinghe <malit...@wso2.com>
> wrote:
>
>>
>>
>> On Fri, Nov 17, 2017 at 6:12 PM, Johann Nallathamby <joh...@wso2.com>
>> wrote:
>>
>>> Hi Farasath,
>>>
>>> On Fri, Nov 17, 2017 at 5:35 PM, Farasath Ahamed <farasa...@wso2.com>
>>> wrote:
>>>
>>>>
>>>> On Fri, Nov 17, 2017 at 3:23 PM, Johann Nallathamby <joh...@wso2.com>
>>>> wrote:
>>>>
>>>>> Self contained JWT's may get quite large and if we set it as the
>>>>> default size in the script, for users who are not using self contained JWT
>>>>> also it is going to consume large space in the database.
>>>>>
>>>>> Did we think about storing a hash of the access token?
>>>>>
>>>>
>>>> As pointed out by Johann JWT can grow large with requested claims etc.
>>>> so changing the column size can happen as soon as the JWT exceeds the
>>>> defined length,
>>>>
>>>> Therefore, We had few discussions offline on options to resolve this.
>>>>
>>>> 1. User a different data type like BLOB/TEXT to store the JWT access
>>>> token and store a hash to improve search. In this approach we will avoid
>>>> the SQL error, but there will be performance drop for normal UUID based
>>>> access tokens.
>>>>
>>>
>>> May be we can introduce a config to say whether we need to hash or not.
>>>
>>>
>>>>
>>>> 2. Not store the self contained access token in the database at all[1].
>>>> Since by definition the self contained access token has all the necessary
>>>> data to validate it we can validate the token on IS during introspection.
>>>> Ideally, the idea behind the self contained access token is to avoid
>>>> introspection. But if required we can do it using the presented the JWT
>>>> itself.(This is how client will validate the access token anyways).
>>>> Downfall of this approach is that we cannot revoke the token since we
>>>> don't anyway keep any reference to the issued token.
>>>>
>>>
>>> We can use the "jti" claim of the JWT as the reference and use it to
>>> manage the token in IS.
>>>
>>
>> So I think you meant that we don't need to persist the self contained
>> access token at all (even the hash) and use an identifier to reference the
>> token issued. And that reference will be returned with the JWT as 'jti'
>> claim.
>>
>
> Yes
>

So we can store the jti as the access_token in the IDN_ACCESS_TOKEN table.
Is my understanding correct?


>
>
>>
>>
>>>
>>> Regards,
>>> Johann.
>>>
>>>
>>>>
>>>> [1] https://www.oauth.com/oauth2-servers/access-tokens/self-
>>>> encoded-access-tokens/
>>>> <https://www.google.com/url?q=https%3A%2F%2Fwww.oauth.com%2Foauth2-servers%2Faccess-tokens%2Fself-encoded-access-tokens%2F=D=1=AFQjCNF5pHN-sGoIgbANyG1WpbRC-dZfSA>
>>>>
>>>>
>>>> Appreciate your thoughts!
>>>>
>>>>
>>>>
>>>>>
>>>>> On Fri, Nov 17, 2017 at 3:06 PM, Isura Karunaratne <is...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Nov 17, 2017 at 1:35 PM, Isura Karunaratne <is...@wso2.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Currently, ACCESS_TOKEN column length is defined as 512 [1] which is
>>>>>>> not enough to store self-contained access token [2].
>>>>>>>
>>>>>>> Shall we increase the column size by default?
>>>>>>>
>>>>>>> Thanks
>>>>>>> Isura.
>>>>>>>
>>>>>>>
>>>>>>> [1]
>>>>>>> CREATE TABLE IF NOT EXISTS IDN_OAUTH2_ACCESS_TOKEN (
>>>>>>> TOKEN_ID VARCHAR (255),
>>>>>>> ACCESS_TOKEN VARCHAR(512),
>>>>>>&g

Re: [Dev] Self Contained Access Tokens in IS 5.4.0

2017-11-17 Thread Farasath Ahamed

On Fri, Nov 17, 2017 at 3:23 PM, Johann Nallathamby  wrote:

> Self contained JWT's may get quite large and if we set it as the default
> size in the script, for users who are not using self contained JWT also it
> is going to consume large space in the database.
>
> Did we think about storing a hash of the access token?
>

As pointed out by Johann JWT can grow large with requested claims etc. so
changing the column size can happen as soon as the JWT exceeds the defined
length,

Therefore, We had few discussions offline on options to resolve this.

1. User a different data type like BLOB/TEXT to store the JWT access token
and store a hash to improve search. In this approach we will avoid the SQL
error, but there will be performance drop for normal UUID based access
tokens.

2. Not store the self contained access token in the database at all[1].
Since by definition the self contained access token has all the necessary
data to validate it we can validate the token on IS during introspection.
Ideally, the idea behind the self contained access token is to avoid
introspection. But if required we can do it using the presented the JWT
itself.(This is how client will validate the access token anyways).
Downfall of this approach is that we cannot revoke the token since we don't
anyway keep any reference to the issued token.

[1] https://www.oauth.com/oauth2-servers/access-tokens/
self-encoded-access-tokens/

Appreciate your thoughts!

>
> On Fri, Nov 17, 2017 at 3:06 PM, Isura Karunaratne  wrote:
>
>>
>>
>> On Fri, Nov 17, 2017 at 1:35 PM, Isura Karunaratne 
>> wrote:
>>
>>> Hi all,
>>>
>>> Currently, ACCESS_TOKEN column length is defined as 512 [1] which is not
>>> enough to store self-contained access token [2].
>>>
>>> Shall we increase the column size by default?
>>>
>>> Thanks
>>> Isura.
>>>
>>>
>>> [1]
>>> CREATE TABLE IF NOT EXISTS IDN_OAUTH2_ACCESS_TOKEN (
>>> TOKEN_ID VARCHAR (255),
>>> ACCESS_TOKEN VARCHAR(512),
>>> REFRESH_TOKEN VARCHAR(512),
>>> CONSUMER_KEY_ID INTEGER,
>>> AUTHZ_USER VARCHAR (100),
>>> TENANT_ID INTEGER,
>>> USER_DOMAIN VARCHAR(50),
>>> USER_TYPE VARCHAR (25),
>>> GRANT_TYPE VARCHAR (50),
>>> TIME_CREATED TIMESTAMP DEFAULT 0,
>>> REFRESH_TOKEN_TIME_CREATED TIMESTAMP DEFAULT 0,
>>> VALIDITY_PERIOD BIGINT,
>>> REFRESH_TOKEN_VALIDITY_PERIOD BIGINT,
>>> TOKEN_SCOPE_HASH VARCHAR(32),
>>> TOKEN_STATE VARCHAR(25) DEFAULT 'ACTIVE',
>>> TOKEN_STATE_ID VARCHAR (128) DEFAULT 'NONE',
>>> SUBJECT_IDENTIFIER VARCHAR(255),
>>> PRIMARY KEY (TOKEN_ID),
>>> FOREIGN KEY (CONSUMER_KEY_ID) REFERENCES
>>> IDN_OAUTH_CONSUMER_APPS(ID) ON DELETE CASCADE,
>>> CONSTRAINT CON_APP_KEY UNIQUE (CONSUMER_KEY_ID,AUTHZ_USER,TE
>>> NANT_ID,USER_DOMAIN,USER_TYPE,TOKEN_SCOPE_HASH,
>>>TOKEN_STATE,TOKEN_STATE_ID)
>>>
>>>
>>> [2] https://wso2.org/jira/browse/IDENTITY-6917
>>>
>>>
>>> --
>>>
>>> *Isura Dilhara Karunaratne*
>>> Associate Technical Lead | WSO2
>>> Email: is...@wso2.com
>>> Mob : +94 772 254 810 <+94%2077%20225%204810>
>>> Blog : http://isurad.blogspot.com/
>>>
>>>
>>>
>>>
>>
>>
>> --
>>
>> *Isura Dilhara Karunaratne*
>> Associate Technical Lead | WSO2
>> Email: is...@wso2.com
>> Mob : +94 772 254 810 <+94%2077%20225%204810>
>> Blog : http://isurad.blogspot.com/
>>
>>
>>
>>
>
>
> --
> 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

[Dev] WSO2 Identity Server 5.4.0 Alpha 9 Released !!!

2017-11-16 Thread Farasath Ahamed

oint using playground sample fails when using email
   as the user name
   - [IDENTITY-6558 <https://wso2.org/jira/browse/IDENTITY-6558>] -
   SAML2.IsPassiveAuthn=true is not available in travelocity.properties
   - [IDENTITY-6581 <https://wso2.org/jira/browse/IDENTITY-6581>] - Error
   with SAML Extension Grant Type
   - [IDENTITY-6703 <https://wso2.org/jira/browse/IDENTITY-6703>] - Bad
   Grammar in the exception: "SAML Assertion not found in the Response"
   - [IDENTITY-6736 <https://wso2.org/jira/browse/IDENTITY-6736>] - All the
   query params in "Additional Query Parameters" of federated oauth/openid
   connect IDP config is not visible in management console
   - [IDENTITY-6797 <https://wso2.org/jira/browse/IDENTITY-6797>] - Stack
   trace of exception displayed in web browser in case of empty SAMLRequest
   - [IDENTITY-6805 <https://wso2.org/jira/browse/IDENTITY-6805>] - NPE
   possibility in NTLMAuthenticationGrantHandler
   - [IDENTITY-6895 <https://wso2.org/jira/browse/IDENTITY-6895>] - Claims
   not returned properly after SP requested claims updated
   - [IDENTITY-6896 <https://wso2.org/jira/browse/IDENTITY-6896>] - Oauth2
   Revoke endpoint does not validate repeated parameters
   - [IDENTITY-6897 <https://wso2.org/jira/browse/IDENTITY-6897>] - Claim
   filtering not handled in UserInfoJWTResponseBuilder
   - [IDENTITY-6898 <https://wso2.org/jira/browse/IDENTITY-6898>] - Revoke
   endpoint sends an Unauthorized response when Invalid Authorization header
   exists, but the token is empty.
   - [IDENTITY-6901 <https://wso2.org/jira/browse/IDENTITY-6901>] -
   Validate subjectConfirmationData time limits to fall within the time window
   given in the Conditions in the saml assertion
   - [IDENTITY-6909 <https://wso2.org/jira/browse/IDENTITY-6909>] - HTML
   tags should be closed properly

Improvement

   - [IDENTITY-2530 <https://wso2.org/jira/browse/IDENTITY-2530>] - Make
   refresh tokens optional for SAML2 Bearer grant type
   - [IDENTITY-4980 <https://wso2.org/jira/browse/IDENTITY-4980>] -
   Exception during access token generation right after expiration
   - [IDENTITY-5483 <https://wso2.org/jira/browse/IDENTITY-5483>] -
   Validate user against given user store and save correct user domain in
   saml2-bearer grant type.
   - [IDENTITY-5975 <https://wso2.org/jira/browse/IDENTITY-5975>] - Need to
   handle errors in oAuth Endpoints
   - [IDENTITY-6224 <https://wso2.org/jira/browse/IDENTITY-6224>] - Improve
   logs in controlClaimsFromScope() of SAMLAssertionClaimsCallback class
   - [IDENTITY-6900 <https://wso2.org/jira/browse/IDENTITY-6900>] - Make
   subject claim consistent across all grant types



*Contribute to WSO2 Identity Server*

*Mailing Lists*

Join our mailing lists and correspond with the developers directly. We also
encourage you to take part in discussions related to the product in the
architecture mailing list. If you have any questions regarding the product
you can use our StackOverflow forum to raise them as well.

   - Developer List: dev@wso2.org
   - Architecture List: architect...@wso2.org
   - User Forum: StackOverflow
   <http://stackoverflow.com/questions/tagged/wso2is>

Reporting Issues
We encourage you to report issues, improvements, and feature requests
regarding WSO2 Identity Server through our public WSO2 Identity Server JIRA
<https://wso2.org/jira/projects/IDENTITY/issues>.

~ The WSO2 Identity and Access Management Team ~



Thanks,
Farasath Ahamed
Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [IS] [OAuth] Validating and renewing an access token with one call.

2017-11-14 Thread Farasath Ahamed

Farasath Ahamed
Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>



On Wed, Nov 15, 2017 at 10:56 AM, Thilina Madumal <thilina...@wso2.com>
wrote:

>
>
> On Wed, Nov 15, 2017 at 9:42 AM, Farasath Ahamed <farasa...@wso2.com>
> wrote:
>
>>
>>
>>
>> On Wed, Nov 15, 2017 at 9:03 AM, Thilina Madumal <thilina...@wso2.com>
>> wrote:
>>
>>> Hi Farazath,
>>>
>>> Thanks for the reply. Please see the inline comments.
>>>
>>> On Tue, Nov 14, 2017 at 11:10 PM, Farasath Ahamed <farasa...@wso2.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Tuesday, November 14, 2017, Thilina Madumal <thilina...@wso2.com>
>>>> wrote:
>>>>
>>>>> Hi Devs,
>>>>>
>>>>> I'm working implementing an SPA that uses OAuth access-token in
>>>>> securing resource access.
>>>>> In the documentation [1] I found that to validate the access token
>>>>> that I already have obtained, the introspection endpoint can be used.
>>>>>
>>>>> My question is, is there a way where I can send both the accesss token
>>>>> and the refresh token, then IS will validate the access token, and if the
>>>>> access token is expired IS will issue a new access token for the given
>>>>> refresh token.
>>>>>
>>>>> I understand that the above use-case can be achieved by 2 requests to
>>>>> the IS. But I'm curious is to know whether there is a way to achieve this
>>>>> by a single request.
>>>>>
>>>>
>>>> Introspection Endpoint is basically an endpoint used to gather validate
>>>> and gather metadata about the access token.
>>>>
>>>> Usually this will be used by a resource server to validate an access
>>>> token presented by an oauth client. Resource server will introspect the
>>>> token to get metadata and authorize access.
>>>>
>>>> Meanwhile, a refresh token flow is between the oauth client and
>>>> authorization server.
>>>>
>>>> So the requirement you have presented does not fit into the
>>>> introspection call/endpoint. ie. Introspection and token refresh in one
>>>> call simply because there are two completely different flows.
>>>>
>>>
>>> In end-user perspective this would be a nice to have feature unless it
>>> is not a spec violation.
>>> On the other hand it do not need to be the introspection endpoint, it
>>> can be some custom endpoint where it takes the access-token and
>>> refresh-token and has the following behavior;
>>>
>>>- if the access-token is still valid return the same accesss-token
>>>and refresh-token.
>>>- if access-token is expired exchange the refresh-token for a new
>>>access-token, and return the new access-token and a new refresh-token.
>>>
>>> Okay in that case we can go for a custom grant type. Grant type will
>> accept an access token and a refresh token and have the behaviour you have
>> described. Anyways if the requirement is to make sure we have an active
>> token all the time why not simply refresh the token :)
>>
>
> Is it a recommended approach? I mean refreshing the access-token
> frequently. Just asking for the curiosity :)
>

There are two options,

1. OAuth client keeps track of the expiry and does a refresh when the token
is about to expiry.
2. OAuth client has a retry mechanism when an the resource server returns
an error when a expired token is used.

>
>
>
>>
>>
>>
>>> Anyhow need to consider the practicality of the use-case furthermore.
>>>
>>>
>>>>
>>>> In you use case why does the SPA have to do the introspection call?
>>>> Shouldn't it be the resource server consumed by SPA that needs to do the
>>>> introspection call.
>>>>
>>>
>>> In this particular use-case the IS is the resource server. The SPA is a
>>> fully browser based application.
>>> To verify the authenticity of the user the SPA uses the access-token it
>>> obtained, that's why the SPA needs to call the introspection endpoint.
>>>
>>
>> From what you have explained. To me IS is the authorization server. SPA
>> is the OAuth2/OIDC client. Since the SPA will recieve the id_

Re: [Dev] [IS] [OAuth] Validating and renewing an access token with one call.

2017-11-14 Thread Farasath Ahamed

On Wed, Nov 15, 2017 at 9:03 AM, Thilina Madumal <thilina...@wso2.com>
wrote:

> Hi Farazath,
>
> Thanks for the reply. Please see the inline comments.
>
> On Tue, Nov 14, 2017 at 11:10 PM, Farasath Ahamed <farasa...@wso2.com>
> wrote:
>
>>
>>
>> On Tuesday, November 14, 2017, Thilina Madumal <thilina...@wso2.com>
>> wrote:
>>
>>> Hi Devs,
>>>
>>> I'm working implementing an SPA that uses OAuth access-token in securing
>>> resource access.
>>> In the documentation [1] I found that to validate the access token that
>>> I already have obtained, the introspection endpoint can be used.
>>>
>>> My question is, is there a way where I can send both the accesss token
>>> and the refresh token, then IS will validate the access token, and if the
>>> access token is expired IS will issue a new access token for the given
>>> refresh token.
>>>
>>> I understand that the above use-case can be achieved by 2 requests to
>>> the IS. But I'm curious is to know whether there is a way to achieve this
>>> by a single request.
>>>
>>
>> Introspection Endpoint is basically an endpoint used to gather validate
>> and gather metadata about the access token.
>>
>> Usually this will be used by a resource server to validate an access
>> token presented by an oauth client. Resource server will introspect the
>> token to get metadata and authorize access.
>>
>> Meanwhile, a refresh token flow is between the oauth client and
>> authorization server.
>>
>> So the requirement you have presented does not fit into the introspection
>> call/endpoint. ie. Introspection and token refresh in one call simply
>> because there are two completely different flows.
>>
>
> In end-user perspective this would be a nice to have feature unless it is
> not a spec violation.
> On the other hand it do not need to be the introspection endpoint, it can
> be some custom endpoint where it takes the access-token and refresh-token
> and has the following behavior;
>
>- if the access-token is still valid return the same accesss-token and
>refresh-token.
>- if access-token is expired exchange the refresh-token for a new
>access-token, and return the new access-token and a new refresh-token.
>
> Okay in that case we can go for a custom grant type. Grant type will
accept an access token and a refresh token and have the behaviour you have
described. Anyways if the requirement is to make sure we have an active
token all the time why not simply refresh the token :)



> Anyhow need to consider the practicality of the use-case furthermore.
>
>
>>
>> In you use case why does the SPA have to do the introspection call?
>> Shouldn't it be the resource server consumed by SPA that needs to do the
>> introspection call.
>>
>
> In this particular use-case the IS is the resource server. The SPA is a
> fully browser based application.
> To verify the authenticity of the user the SPA uses the access-token it
> obtained, that's why the SPA needs to call the introspection endpoint.
>

>From what you have explained. To me IS is the authorization server. SPA is
the OAuth2/OIDC client. Since the SPA will recieve the id_token which is
signed by IS. We should use that to verify the authenticity of the user.
Moreoever user details in an instrospection call is optional so we can't
rely on it to authenticate the user where as id_token is tailored for user
authenticationa and guranteed to contain the identifier of the user as
'sub' claim.

>
>
>
>>
>> If the resource server throws an error due to an invalid access token
>> then the SPA can do the refresh call and get a new token.
>>
>>>
>>> [1] https://docs.wso2.com/display/IS530/Invoke+the+OAuth+Int
>>> rospection+Endpoint
>>>
>>> Best,
>>> Thilina
>>> --
>>> *Thilina Madumal*
>>> *Software Engineer | **WSO2*
>>> Email: thilina...@wso2.com
>>> Mobile: *+ <+94%2077%20767%201807>94 774553167*
>>> Web:  <http://goog_716986954>http://wso2.com
>>>
>>> <http://wso2.com/signature>
>>>
>>>
>>
>> --
>> Farasath Ahamed
>> Software Engineer, WSO2 Inc.; http://wso2.com
>> Mobile: +94777603866
>> Blog: blog.farazath.com
>> Twitter: @farazath619 <https://twitter.com/farazath619>
>> <http://wso2.com/signature>
>>
>>
>>
>>
>
>
> --
> *Thilina Madumal*
> *Software Engineer | **WSO2*
> Email: thilina...@wso2.com
> Mobile: *+ <+94%2077%20767%201807>94 774553167*
> Web:  <http://goog_716986954>http://wso2.com
>
> <http://wso2.com/signature>
>
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [IS] [OAuth] Validating and renewing an access token with one call.

2017-11-14 Thread Farasath Ahamed

On Tuesday, November 14, 2017, Thilina Madumal <thilina...@wso2.com> wrote:

> Hi Devs,
>
> I'm working implementing an SPA that uses OAuth access-token in securing
> resource access.
> In the documentation [1] I found that to validate the access token that I
> already have obtained, the introspection endpoint can be used.
>
> My question is, is there a way where I can send both the accesss token and
> the refresh token, then IS will validate the access token, and if the
> access token is expired IS will issue a new access token for the given
> refresh token.
>
> I understand that the above use-case can be achieved by 2 requests to the
> IS. But I'm curious is to know whether there is a way to achieve this by a
> single request.
>

Introspection Endpoint is basically an endpoint used to gather validate and
gather metadata about the access token.

Usually this will be used by a resource server to validate an access token
presented by an oauth client. Resource server will introspect the token to
get metadata and authorize access.

Meanwhile, a refresh token flow is between the oauth client and
authorization server.

So the requirement you have presented does not fit into the introspection
call/endpoint. ie. Introspection and token refresh in one call simply
because there are two completely different flows.

In you use case why does the SPA have to do the introspection call?
Shouldn't it be the resource server consumed by SPA that needs to do the
introspection call.

If the resource server throws an error due to an invalid access token then
the SPA can do the refresh call and get a new token.

>
> [1] https://docs.wso2.com/display/IS530/Invoke+the+
> OAuth+Introspection+Endpoint
>
> Best,
> Thilina
> --
> *Thilina Madumal*
> *Software Engineer | **WSO2*
> Email: thilina...@wso2.com
> <javascript:_e(%7B%7D,'cvml','thilina...@wso2.com');>
> Mobile: *+ <+94%2077%20767%201807>94 774553167*
> Web:  <http://goog_716986954>http://wso2.com
>
> <http://wso2.com/signature>
>
>

-- 
Farasath Ahamed
Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] SPML Outbound provisioning Use case

2017-11-13 Thread Farasath Ahamed

Hi Ushani,

When you configure an outbound provisioning to *Resident Service Provider, *any
changes you do to local users will be provisioned to configured outbound
provisioning connectors.

So,

SCIM Call ---> Resident SP --> Provision using SPML.

By configuring an outbound provisioning connector you are asking IS to sync
any changes(any CRUD operation) you do to a local user (in a user store)
with an external entity. You would observe the same behaviour even if you
add a user from the management console.

Any CRUD to local user ---> Resident SP --> Trigger outbound provisioning
connectors.

Any particular reason you are trying out SPML since it's a deprecated
connector?

Thanks,
Farasath

Farasath Ahamed
Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>

On Mon, Nov 13, 2017 at 6:31 PM, Ushani Balasooriya <ush...@wso2.com> wrote:

> Hi IAM Team,
>
>
> Can you please explain me how does SPML outbound connector works?
>
> In my scenario, I am adding a user via SCIM and trying to update the user
> via SCIM. I have enabled SPML connector and added it under resident service
> provider.
>
> When I add a user via SCIM, I get the below warning. Please explain why it
> triggers SPML connector when I add a user via SCIM.
>
> I cannot find enough information in this doc [1]
>
> [1] https://docs.wso2.com/display/IS530/Outbound+Provisioning+with+SPML
>
> [2017-11-13 18:26:39,204]  WARN {org.wso2.carbon.identity.
> provisioning.connector.spml.SPMLProvisioningConnector} -  Unsupported
> provisioning opertaion.
> [2017-11-13 18:26:39,212]  WARN {org.wso2.carbon.identity.
> provisioning.connector.spml.SPMLProvisioningConnector} -  Unsupported
> provisioning opertaion.
> [2017-11-13 18:26:39,218]  WARN {org.wso2.carbon.identity.
> provisioning.connector.spml.SPMLProvisioningConnector} -  Unsupported
> provisioning opertaion.
> [2017-11-13 18:26:39,227] ERROR {org.wso2.carbon.identity.
> provisioning.connector.spml.SPMLProvisioningConnector} -  Error while
> SPML user updating
>
>
>
> Thanks,
> --
> *Ushani Balasooriya*
> Associate Technical Lead - EE;
> WSO2 Inc; http://www.wso2.com/.
> Mobile; +94772636796
>
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [IS][OAuth] Token Response request validation

2017-11-02 Thread Farasath Ahamed

Had a look at the code and looks like we are doing a redundant check in the
two methods.
Ideally, we should only have this logic in isAuthorizedClient() method.

IMO your analysis is correct and we should remove the redundant logic.

We have similar methods in AuthorizationGrantHandler interface as well.
There,
1. isAuthorizedClient() method validates whether the client is using an
allowed grant type
2. authorizeAccessDelegation() is used to fire callback handlers to achieve
scope validation logic etc. (ie. to validate whether the authorized user is
allowed to request the particular scope)[2]


[1]
https://github.com/wso2-extensions/identity-inbound-auth-oauth/blob/c8683a407b22327fb57492dda313ca665d0d29f9/components/org.wso2.carbon.identity.oauth/src/main/java/org/wso2/carbon/identity/oauth2/token/handlers/grant/AbstractAuthorizationGrantHandler.java#L675-L675

[2]
https://github.com/wso2-extensions/identity-inbound-auth-oauth/blob/c8683a407b22327fb57492dda313ca665d0d29f9/components/org.wso2.carbon.identity.oauth/src/main/java/org/wso2/carbon/identity/oauth2/token/handlers/grant/AbstractAuthorizationGrantHandler.java#L605-L605


Thanks,
Farasath




Farasath Ahamed
Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>



On Thu, Nov 2, 2017 at 2:54 PM, Danushka Fernando <danush...@wso2.com>
wrote:

> Hi All
> When access token, id token, auth code or open id token is requested, it
> will go through AuthorizationHandlerManager[1] class to authorize the
> client. There are three authorization steps [2].
>
>1. First check is isAuthorized check. Here it checks whether its
>requesting a token or a code and according to that it will check implicit
>or code grant types are allowed for the application and returns true of
>false.[3]
>2. Second check is validateAccessDelegation check. Here also it checks
>the request type and will check allowance of implicit or code grant types
>and returns true or false.[4]
>3. Third is scope validation
>
> So according to this analysis both check #1 and #2 are doing the same
> thing and I don't see a way of check #1 getting passed and check #2 getting
> failed. Please correct me if I am wrong.
>
> If this is correct shall we do the necessary adjustment to reduce the
> complexity of the code?
>
>
> [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/authz/
> AuthorizationHandlerManager.java
> [2] 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/authz/
> AuthorizationHandlerManager.java#L100-L123
> [3] 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/authz/handlers/AbstractResponseTypeHandler.java#L128-L165
> [4] 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/authz/handlers/AbstractResponseTypeHandler.java#L66-L104
>
> Thanks & Regards
> Danushka Fernando
> Associate Tech Lead
> WSO2 inc. http://wso2.com/
> Mobile : +94716332729 <+94%2071%20633%202729>
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Correct way to Add users and Roles via an API

2017-11-01 Thread Farasath Ahamed

On Wed, Nov 1, 2017 at 7:38 PM, Ushani Balasooriya  wrote:

> Hi IAM team,
>
> I am trying to implement a thirdparty web app to manage users and roles
> functionalities as explained in this blog post [1] Solution 26.
>
> According to the solution, it says,
>
> *"The WSO2 Identity Server exposes a set of REST endpoints as well as
> SOAP-based services for user management, the web app just need to talk to
> these endpoints, without having to deal directly with underlying user
> stores (LDAP, AD, JDBC)."*
>
> This [2] is the only document I can find as the available API for user
> role management.
>
> Please verify whether my below understandings are correct to proceed with
> this solution.
>
> 1. Since WSO2IS does not provide any REST API for user/role management,
> there will not be a particular API where I can use as endpoint in my third
> party application.
> Therefore my web app should use a class as explained in this [2] document.
>
> 2. We should not consider SCIM as REST endpoint to manage users since it
> is used to provision users to external system. Therefore I cannot treat
> SCIM as a REST endpoint which can use to add users and roles.
>

IMO this is not entirely correct.
SCIM inbound connector is used to provision users *in to* Identity Server
and the SCIM outbound connector can be used provision user to external
systems as you explained.

SCIM inbound connector exposes a REST endpoint through which you can do
CRUD operation on users/groups. This can be considered as a REST endpoint
to manage users. Both SCIM and our SOAP APIs talk to the same underlying
user-core impelementation to achieve CRUD on users (user stores).

Moreover SCIM simply provides a RESTful layer over our usercore
funcionality. So I don't see why we should not consider SCIM as a REST API
to manage users.
Infact we have customers using SCIM to achieve user registration, user
profile update etc.

>
>
> [1] https://medium.facilelogin.com/thirty-solution-patterns-
> with-the-wso2-identity-server-16f9fd0c0389
>
> [2] https://docs.wso2.com/display/IS530/Managing+Users+and+
> Roles+with+APIs#ManagingUsersandRoleswithAPIs-addRole()
>
> Thanks,
> --
> *Ushani Balasooriya*
> Associate Technical Lead - EE;
> WSO2 Inc; http://www.wso2.com/.
>
>
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] UserAccountAssociationService having “/permission/admin/login” permissions in some operations

2017-10-30 Thread Farasath Ahamed

Hi Rumy,

If we can identify the users we want to restrict access by a particular
role, Let's say 'X'. We can achieve your requirement as follows,

1. Add management console as a service provider in IS ( Ref:
https://medium.com/@PrakhashS/enabling-multi-factor-authentication-for-wso2-identity-server-management-console-c4e247cd553f
)

2. Engage Authorization for the service provider representing the
management console. (Ref:
https://medium.com/@pulasthi7/application-authorization-using-wso2-identity-server-1-introduction-3f2e0898b43e
)

3. We can engage an XACML policy which restricts login to users with role
'X'


Thanks,
Farasath

Farasath Ahamed
Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>



On Sun, Oct 29, 2017 at 10:53 PM, Mushthaq Rumy <musht...@wso2.com> wrote:

> @Farasath - These users will have roles assigned to them.
>
> Thanks & Regards,
> Mushthaq
>
> On Sun, Oct 29, 2017 at 1:01 AM, Farasath Ahamed <farasa...@wso2.com>
> wrote:
>
>>
>>
>> On Friday, October 27, 2017, Mushthaq Rumy <musht...@wso2.com> wrote:
>>
>>> Hi Thanuja,
>>>
>>> Thanks for the clarification. One more thing. Is there a way that we can
>>> avoid specific users to login to the Management Console who has "
>>> permission/admin/login" permission?
>>>
>>
>> Can we identify these users based on their role or some other attribute?
>>
>>
>>
>>> Thanks & Regards,
>>> Mushthaq
>>>
>>> On Thu, Oct 26, 2017 at 7:28 PM, Thanuja Jayasinghe <than...@wso2.com>
>>> wrote:
>>>
>>>> Hi Mushthaq,
>>>>
>>>> UserAccountAssociationService.switchLoggedInUser() service method is
>>>> only useful for users who has logged in session. Because this feature
>>>> provides support for switch between associated user accounts in that logged
>>>> in session. In order to create a session we need to call A
>>>> uthenticationAdmin.login() and in this service method, we do check
>>>> whether the user has permission/admin/login permission[1]. So it is a
>>>> must to have permission/admin/login permission for any user who is
>>>> using switchLoggedInUser method.
>>>>
>>>> I think this gives the rationality for other methods which have the
>>>> same permission level.
>>>>
>>>> [1] - https://github.com/wso2/carbon-kernel/blob/4.4.x/core/org.ws
>>>> o2.carbon.core.services/src/main/java/org/wso2/carbon/core/s
>>>> ervices/authentication/AuthenticationAdmin.java#L110
>>>>
>>>> Thanks,
>>>> Thanuja
>>>>
>>>> On Thu, Oct 26, 2017 at 6:18 PM, Mushthaq Rumy <musht...@wso2.com>
>>>> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> Is there a specific reason to have "/permission/admin/login" in some
>>>>> of the operations in UserAccountAssociationService?
>>>>>
>>>>> This permission will allow the users to login to the Management
>>>>> Console and In case, if someone wants to use these operations of
>>>>> UserAccountAssociationService in a separate client application and he/she
>>>>> does not want to the users of this application to login to the Management
>>>>> Console, what would be the work around and how can we solve this?
>>>>>
>>>>> Your thoughts on this is highly appreciated.
>>>>>
>>>>> Thanks & Regards,
>>>>> Mushthaq
>>>>> --
>>>>> Mushthaq Rumy
>>>>> *Software Engineer*
>>>>> Mobile : +94 (0) 779 492140 <%2B94%20%280%29%20773%20451194>
>>>>> Email : musht...@wso2.com
>>>>> WSO2, Inc.; http://wso2.com/
>>>>> lean . enterprise . middleware.
>>>>>
>>>>> <http://wso2.com/signature>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> *Thanuja Lakmal*
>>>> Associate Technical Lead
>>>> WSO2 Inc. http://wso2.com/
>>>> *lean.enterprise.middleware*
>>>> Mobile: +94715979891
>>>>
>>>
>>>
>>>
>>> --
>>> Mushthaq Rumy
>>> *Software Engineer*
>>> Mobile : +94 (0) 779 492140 <%2B94%20%280%29%20773%20451194>
>>> Email : musht...@wso2.com
>>> WSO2, Inc.; http://wso2.com/
>>> lean . enterprise . middleware.
>>>
>>> <http://wso2.com/signature>
>>>
>>
>>
>> --
>> Farasath Ahamed
>> Software Engineer, WSO2 Inc.; http://wso2.com
>> Mobile: +94777603866
>> Blog: blog.farazath.com
>> Twitter: @farazath619 <https://twitter.com/farazath619>
>> <http://wso2.com/signature>
>>
>>
>>
>>
>
>
> --
> Mushthaq Rumy
> *Software Engineer*
> Mobile : +94 (0) 779 492140 <%2B94%20%280%29%20773%20451194>
> Email : musht...@wso2.com
> WSO2, Inc.; http://wso2.com/
> lean . enterprise . middleware.
>
> <http://wso2.com/signature>
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] UserAccountAssociationService having “/permission/admin/login” permissions in some operations

2017-10-28 Thread Farasath Ahamed

On Friday, October 27, 2017, Mushthaq Rumy <musht...@wso2.com> wrote:

> Hi Thanuja,
>
> Thanks for the clarification. One more thing. Is there a way that we can
> avoid specific users to login to the Management Console who has "
> permission/admin/login" permission?
>

Can we identify these users based on their role or some other attribute?



> Thanks & Regards,
> Mushthaq
>
> On Thu, Oct 26, 2017 at 7:28 PM, Thanuja Jayasinghe <than...@wso2.com
> <javascript:_e(%7B%7D,'cvml','than...@wso2.com');>> wrote:
>
>> Hi Mushthaq,
>>
>> UserAccountAssociationService.switchLoggedInUser() service method is
>> only useful for users who has logged in session. Because this feature
>> provides support for switch between associated user accounts in that logged
>> in session. In order to create a session we need to call A
>> uthenticationAdmin.login() and in this service method, we do check
>> whether the user has permission/admin/login permission[1]. So it is a
>> must to have permission/admin/login permission for any user who is using
>> switchLoggedInUser method.
>>
>> I think this gives the rationality for other methods which have the same
>> permission level.
>>
>> [1] - https://github.com/wso2/carbon-kernel/blob/4.4.x/core/org.
>> wso2.carbon.core.services/src/main/java/org/wso2/carbon/core
>> /services/authentication/AuthenticationAdmin.java#L110
>>
>> Thanks,
>> Thanuja
>>
>> On Thu, Oct 26, 2017 at 6:18 PM, Mushthaq Rumy <musht...@wso2.com
>> <javascript:_e(%7B%7D,'cvml','musht...@wso2.com');>> wrote:
>>
>>> Hi All,
>>>
>>> Is there a specific reason to have "/permission/admin/login" in some of
>>> the operations in UserAccountAssociationService?
>>>
>>> This permission will allow the users to login to the Management Console
>>> and In case, if someone wants to use these operations of
>>> UserAccountAssociationService in a separate client application and he/she
>>> does not want to the users of this application to login to the Management
>>> Console, what would be the work around and how can we solve this?
>>>
>>> Your thoughts on this is highly appreciated.
>>>
>>> Thanks & Regards,
>>> Mushthaq
>>> --
>>> Mushthaq Rumy
>>> *Software Engineer*
>>> Mobile : +94 (0) 779 492140 <%2B94%20%280%29%20773%20451194>
>>> Email : musht...@wso2.com
>>> <javascript:_e(%7B%7D,'cvml','musht...@wso2.com');>
>>> WSO2, Inc.; http://wso2.com/
>>> lean . enterprise . middleware.
>>>
>>> <http://wso2.com/signature>
>>>
>>
>>
>>
>> --
>> *Thanuja Lakmal*
>> Associate Technical Lead
>> WSO2 Inc. http://wso2.com/
>> *lean.enterprise.middleware*
>> Mobile: +94715979891
>>
>
>
>
> --
> Mushthaq Rumy
> *Software Engineer*
> Mobile : +94 (0) 779 492140 <%2B94%20%280%29%20773%20451194>
> Email : musht...@wso2.com
> <javascript:_e(%7B%7D,'cvml','musht...@wso2.com');>
> WSO2, Inc.; http://wso2.com/
> lean . enterprise . middleware.
>
> <http://wso2.com/signature>
>


-- 
Farasath Ahamed
Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] WSO2 Identity Server 5.4.0 Alpha6 Released!

2017-10-26 Thread Farasath Ahamed

ometime

Task

   - [IDENTITY-6551 <https://wso2.org/jira/browse/IDENTITY-6551>] - Update
   x509Authenticator in IS 5.4.0

Improvement

   - [IDENTITY-2944 <https://wso2.org/jira/browse/IDENTITY-2944>] - OIDC
   returns only the claims that are at both "http://wso2.org/oidc/claim;
   and default dialect
   - [IDENTITY-3542 <https://wso2.org/jira/browse/IDENTITY-3542>] -
   Improvements/Fixes to SSO Agent Library
   - [IDENTITY-5121 <https://wso2.org/jira/browse/IDENTITY-5121>] -
   Dashboard "Authorized Apps" gadget be shown only to users with permission
   to list apps operation
   - [IDENTITY-5200 <https://wso2.org/jira/browse/IDENTITY-5200>] -
   alphabetize the list of roles
   - [IDENTITY-5567 <https://wso2.org/jira/browse/IDENTITY-5567>] -
   Implement Ask Password feature in Management console
   - [IDENTITY-5637 <https://wso2.org/jira/browse/IDENTITY-5637>] - Getting
   error after the idle timeout on calling /Authorize?prompt=none
   - [IDENTITY-5937 <https://wso2.org/jira/browse/IDENTITY-5937>] - Update
   the OAuth component SCR plugin version to 1.8.0
   - [IDENTITY-5949 <https://wso2.org/jira/browse/IDENTITY-5949>] - Needs
   to change the pop-up error message with useful details
   - [IDENTITY-6200 <https://wso2.org/jira/browse/IDENTITY-6200>] - Send
   custom errors propagated from Authentication Framework to RP via the OAuth2
   Authorization Endpoint
   - [IDENTITY-6454 <https://wso2.org/jira/browse/IDENTITY-6454>] -
   Capability to restrict case sensitivity in case sensitive userstores from
   IS level
   - [IDENTITY-6620 <https://wso2.org/jira/browse/IDENTITY-6620>] - In
   "Password Policy Authenticator" if decimal value is provided ( represent
   half day ) the signin process fails
   - [IDENTITY-6655 <https://wso2.org/jira/browse/IDENTITY-6655>] - SCIM2
   connector claim-config-diff instruction is misleading



*Contribute to WSO2 Identity Server*

*Mailing Lists*

Join our mailing lists and correspond with the developers directly. We also
encourage you to take part in discussions related to the product in the
architecture mailing list. If you have any questions regarding the product
you can use our StackOverflow forum to raise them as well.

   - Developer List: dev@wso2.org
   - Architecture List: architect...@wso2.org
   - User Forum: StackOverflow
   <http://stackoverflow.com/questions/tagged/wso2is>

Reporting Issues
We encourage you to report issues, improvements, and feature requests
regarding WSO2 Identity Server through our public WSO2 Identity Server JIRA
<https://wso2.org/jira/projects/IDENTITY/issues>.



~ The WSO2 Identity and Access Management Team ~


Thanks,
Farasath Ahamed
Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Enable Response signing cannot be done through admin service when creating SAML2 Web SSO Configuraton for a Service Provider

2017-10-21 Thread Farasath Ahamed

I suspect a caching issue here.
Was this a single node setup or a multi node cluster?

Also when you try out next time. Can you simply view the SP config and
click the update button (without ticking and unticking) and see it it works?

On Friday, October 20, 2017, Chamara Ariyarathne <chama...@wso2.com> wrote:

> Hi all,
>
> I'm using the IdentitySAMLSSOConfigService admin service to do the SAML2
> Web SSO Configuration and later using IdentityApplicationManagementService
> admin service to add it to a service provider configuration.
>
> I am using this tag to Enable Response Signing.
> true
>
> However when later checked with the travelocity webapp and the log
> in fails. When I checked the SP configuration, I can see the checkbox is
> ticked for Enable Response Signing in the UI.
>
> If I untick and tick again the checkbox and update the SP, then the
> scenario passes. What that means is, the admin service cannot be used to
> make the Enable Response Signing.
>
> This needs a fix.
>
> https://wso2.org/jira/browse/IDENTITY-6796
>
> --
> *Chamara Ariyarathne*
> WSO2 Inc; http://www.wso2.com/
> Mobile; *+94772786766*
>


-- 
Farasath Ahamed
Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [APIM] Testing for Offline Microgateway

2017-10-18 Thread Farasath Ahamed

Hi Sabeena,
On Wednesday, October 18, 2017, Sabeena Kumrawadu <sabe...@wso2.com> wrote:

> Hi all,
>
> I have to test the Offline Microgateway, which I finished building
> recently,
>
> To introduce about the Offline Microgateway, it can be started
> independantly, and has no connection with the API Core, where the
> authentication is done with the API keys.
>
> User only has to give the API bal files and the API swagger files of each
> APIS to start the gateway.
>
> Currently it has been suggested to build an API client with the Jersey
> client. What would be the best way of creting an API client for this task?
>

By API Client you mean clients for each API we deploy?

>
> Thanks and Regards.
>
> --
> *Sabeena Kumarawadu* | Software Engineering Intern
> WSO2 Lanka (Pvt) Ltd.
> #20, Palm Grove, Colombo 03, Sri Lanka
> Mobile: +94 71 0372856
> Email: sabe...@wso2.com <javascript:_e(%7B%7D,'cvml','sabe...@wso2.com');>
> [image: http://wso2.com/signature] <http://wso2.com/signature>
>
>

-- 
Farasath Ahamed
Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] How to mock the CarbonContext?

2017-10-10 Thread Farasath Ahamed

Yes, this worked for me.

System.setProperty("carbon.home", "");
PrivilegedCarbonContext.startTenantFlow();

Thereafter you can access PrivilegedCarbonContext.getThreadLocalCarbonContext()
as explained by KasunG



Farasath Ahamed
Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>




On Tue, Oct 10, 2017 at 10:56 AM, KasunG Gajasinghe <kas...@wso2.com> wrote:

>
> Please note that you need to set the carbon.home system property before
> initializing privilegedcarboncontext.
>
> System.setProperty("carbon.home", );
>
> On Thu, Oct 5, 2017 at 12:18 AM, KasunG Gajasinghe <kas...@wso2.com>
> wrote:
>
>>
>> CarbonContext is a thread-local variable. That means the carbon context
>> can be accessible from anywhere within a given thread. So, you may not need
>> to mock it!
>>
>> Since the test class and the testing class runs in the same thread, we
>> can try to populate the CarbonContext in the @Test method before actual
>> testing class invocations.
>>
>> Please see the following code example:
>>
>> @Test
>> public void testSetClaimValue() throws Exception{
>> try {
>> PrivilegedCarbonContext.startTenantFlow();
>> PrivilegedCarbonContext.getThreadLocalCarbonContext().setTen
>> antDomain(MultitenantConstants.SUPER_TENANT_DOMAIN_NAME);
>> PrivilegedCarbonContext.getThreadLocalCarbonContext().setTen
>> antId(MultitenantConstants.SUPER_TENANT_ID);
>>
>> //actual test code and assertions
>>
>> } finally {
>> PrivilegedCarbonContext.endTenantFlow();
>> }
>>
>> }
>>
>> We of course need to test this out. But I think this is ideal if this
>> works.
>>
>>
>>
>> On Wed, Oct 4, 2017 at 10:42 PM, Dharshana Warusavitharana <
>> dharsha...@wso2.com> wrote:
>>
>>> Hi Sivaramya,
>>>
>>> You dont have to mock the whole carbon context here. You can send a mock
>>> payload when the particular method is called.
>>>
>>> Are you using powerMock + mockito if so do as the document sample in [1].
>>>
>>> [1]. https://github.com/searls/mockito-testng-example/blob/m
>>> aster/presentation/Mockito.pdf
>>>
>>> Thank you,
>>> Dharshana.
>>>
>>>
>>>
>>> On Wed, Oct 4, 2017 at 9:55 PM, Malaka Silva <mal...@wso2.com> wrote:
>>>
>>>> +Dharshana
>>>>
>>>> On Wed, Oct 4, 2017 at 8:26 PM, Sivaramya Sivanathan <
>>>> sivara...@wso2.com> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Currently I am working on the unit testing for the esb-connector-jms
>>>>> extension. For that I need to mock the CarbonContext for the method
>>>>> CarbonContext.getThreadLocalCarbonContext().getTenantId(). But, I'm
>>>>> unable mock the CarbonContext.
>>>>> Can any one suggest me how can we mock the CarbonContext?
>>>>>
>>>>> Thanks,
>>>>> Sivaramya Sivanathan
>>>>> Associate Software Engineer | WSO2
>>>>> Tel: 0770874960 <077%20087%204960>
>>>>> WSO2 Inc : http://wso2.org
>>>>> <http://www.google.com/url?q=http%3A%2F%2Fwso2.org=D=1=AFQjCNE_eTDfyl2ibPcq0hcXvRDNVuQmMg>
>>>>> LinkedIn | www.linkedin.com/in/sivaramya
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Best Regards,
>>>>
>>>> Malaka Silva
>>>> Associate Director / Architect
>>>> M: +94 777 219 791 <077%20721%209791>
>>>> Tel : 94 11 214 5345
>>>> Fax :94 11 2145300 <011%202%20145300>
>>>> Skype : malaka.sampath.silva
>>>> LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77
>>>> Blog : http://mrmalakasilva.blogspot.com/
>>>>
>>>> WSO2, Inc.
>>>> lean . enterprise . middleware
>>>> https://wso2.com/signature
>>>> http://www.wso2.com/about/team/malaka-silva/
>>>> <http://wso2.com/about/team/malaka-silva/>
>>>> https://store.wso2.com/store/
>>>>
>>>> Don't make Trees rare, we should keep them with care
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> Dharshana Warusavitharana
>>> Associate Technical Lead
>>> WSO2 Inc. http://wso2.com
>>> email : dharsha...@wso2.com <dharsha...@wso2.com>
>>> Tel  : +94 11 214 5345
>>> Fax :+94 11 2145300 <011%202%20145300>
>>> cell : +94770342233 <077%20034%202233>
>>> blog : http://dharshanaw.blogspot.com
>>>
>>> lean . enterprise . middleware
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>>
>> *Kasun Gajasinghe*Associate Technical Lead, WSO2 Inc.
>> email: kasung AT spamfree wso2.com
>> linked-in: http://lk.linkedin.com/in/gajasinghe
>> blog: http://kasunbg.org
>> phone: +1 650-745-4499 <+1%20650-745-4499>, 77 678 0813
>>
>>
>
>
>
> --
>
> *Kasun Gajasinghe*Associate Technical Lead, WSO2 Inc.
> email: kasung AT spamfree wso2.com
> linked-in: http://lk.linkedin.com/in/gajasinghe
> blog: http://kasunbg.org
> phone: +1 650-745-4499 <(650)%20745-4499>, 77 678 0813
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [IS][XACML] Introducing a Custom functionId

2017-10-07 Thread Farasath Ahamed

How did you try to use the function you registered?
Can you provide a sample?

Farasath Ahamed
Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>



On Thu, Oct 5, 2017 at 7:20 PM, Isuranga Perera <isurangamper...@gmail.com>
wrote:

> Hi All,
>
> I'm trying to introduce a new XACML function in IS 5.3. This is the
> procedure I followed so far.
>
>- Create the new class by extending the *FunctionBase* abstract class.
>- Created a jar file and copied it into
>*/repository/components/lib* directory
>- Created "balana-config.xml" file with the following content and
>copied it into */repository/conf/security*
>
>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
> * defaultAttributeFactory="attr" defaultCombiningAlgFactory="comb"
> defaultFunctionFactory="func">   class="org.wso2.balana.finder.impl.CurrentEnvModule"/>
>   class="org.wso2.balana.finder.impl.SelectorModule"/>   name="attr" useStandardDatatypes="true"/>  useStandardFunctions="true">   class="org.wso2.xacml.permissions.PermissionEvalFunction"/>
> useStandardAlgorithms="true" />*
>
>- Set property
>
>*PDP.Balana.Config.Enable=true *in
>*/repository/conf/identity/entitlement.properties*
>
> But when I tried to use that functionId in a policy it throws an Exception
> saying functionId doesn't exist. It seems even my config file is not parsed.
> Appreciate any help.
>
> Best Regards,
> Isuranga Perera
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Please review and merge PR

2017-09-19 Thread Farasath Ahamed

Thanks Thusitha!

On Tuesday, September 19, 2017, Thusitha Thilina Dayaratne <
thusit...@wso2.com> wrote:

> Hi Farasath,
>
> Merged the PR.
>
>
>
>
> On Tue, Sep 19, 2017 at 6:36 PM, Farasath Ahamed <farasa...@wso2.com
> <javascript:_e(%7B%7D,'cvml','farasa...@wso2.com');>> wrote:
>
>> Hi,
>>
>> Can you please review and merge the following PR[1]. This needs to go
>> into Kernel 4.4.18
>>
>> [1] https://github.com/wso2/carbon-kernel/pull/1538
>>
>>
>>
>>
>> Thanks,
>> Farasath Ahamed
>> Software Engineer, WSO2 Inc.; http://wso2.com
>> Mobile: +94777603866
>> Blog: blog.farazath.com
>> Twitter: @farazath619 <https://twitter.com/farazath619>
>> <http://wso2.com/signature>
>>
>>
>>
>
>
> --
> Thusitha Dayaratne
> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>
> Mobile  +94712756809
> Blog  alokayasoya.blogspot.com
> Abouthttp://about.me/thusithathilina
> <http://wso2.com/signature>
>
>

-- 
Farasath Ahamed
Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] Please review and merge PR

2017-09-19 Thread Farasath Ahamed

Hi,

Can you please review and merge the following PR[1]. This needs to go into
Kernel 4.4.18

[1] https://github.com/wso2/carbon-kernel/pull/1538




Thanks,
Farasath Ahamed
Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

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

2017-09-16 Thread Farasath Ahamed

On Sat, Sep 16, 2017 at 1:38 PM, Johann Nallathamby <joh...@wso2.com> 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 <hasin...@wso2.com>
> 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 <farasa...@wso2.com>
>>> 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 <hasin...@wso2.com>
>>>>> 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
&

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

2017-09-16 Thread 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.

2017-09-15 Thread Farasath Ahamed

Based on the spec,

To support open Dynamic Registration, the Client Registration Endpoint
> SHOULD accept registration requests without OAuth 2.0 Access Tokens. These
> requests MAY be rate-limited or *otherwise limited to prevent a
> denial-of-service attack* on the Client Registration Endpoint. If an
> Initial Access Token is required for Client registration, the Client
> Registration Endpoint MUST be able to accept these Access Tokens in the
> manner described in the OAuth 2.0 Bearer Token Usage [RFC6750]
> specification.


So our current implementation is not entirely deviating from the
specification. However, I feel it would be better if we could support the
case of making the Client Registration Endpoint open if someone opts to do
so (ie. remove authentication) as you have suggested.




Farasath Ahamed
Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>



On Fri, Sep 15, 2017 at 2:47 PM, Hasini Witharana <hasi...@wso2.com> 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.
>
> [1] - https://openid.net/specs/openid-connect-registration-1_0.html
>
> --
>
> *Hasini Witharana*
> Software Engineering Intern | WSO2
>
>
> *Email : hasi...@wso2.com <hasi...@wso2.com>*
>
> *Mobile : +94713850143 <+94%2071%20385%200143>[image:
> http://wso2.com/signature] <http://wso2.com/signature>*
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Where can I find /token endpoint source code.

2017-09-06 Thread Farasath Ahamed

On Tue, Sep 5, 2017 at 10:39 PM, Farasath Ahamed <farasa...@wso2.com> wrote:

> Hi Shiva,
>
> Please use reply all including the dev list :) So that others will be able
> to chip in with their ideas as well...
>
> There is a small catch there. Even if you managed to pass the
> tenantDomain as a query param to the token endpoint it will not reach your
> extended password grant handler. The reason is this line of code in our
> current implementation[1], which limits the password grant type to pass
> username, password parameters only to the grant handler. We have fixed this
> in master where we pass all the parameters sent in the token.
>
> There is a small trick to get this working. You can write a grant handler
> extending the password grant handler but register it as a custom grant
> instead of grant_type=password, let's say you register it as
> grant_type=custom1, then in the token request you can send the
> tenantDomain as a parameter like below,
>
> "grant_type=custom1=ddd=abc.com",
>
> within the grant handler, you can access any parameter sent using,
>
>  // extract request parameters
>  RequestParameter[] parameters = oAuthTokenReqMessageContext.
> getOauth2AccessTokenReqDTO().getRequestParameters();
>
> All the details you need to implement a custom grant type are in [2] with
> examples. Give it a try! :)
>
>
> [1] https://github.com/wso2-support/identity-inbound-auth-oa
> uth/blob/support-5.3.3/components/org.wso2.carbon.identity.
> oauth.endpoint/src/main/java/org/wso2/carbon/identity/
> oauth/endpoint/token/OAuth2TokenEndpoint.java#L273-L275
>

Correct link

https://github.com/wso2-extensions/identity-inbound-auth-oauth/blob/v5.3.3/components/org.wso2.carbon.identity.oauth.endpoint/src/main/java/org/wso2/carbon/identity/oauth/endpoint/token/OAuth2TokenEndpoint.java#L257-L287







> [2] https://docs.wso2.com/display/IS530/Writing+a+
> Custom+OAuth+2.0+Grant+Type
>
>
> Thanks,
> Farasath Ahamed
> Software Engineer, WSO2 Inc.; http://wso2.com
> Mobile: +94777603866
> Blog: blog.farazath.com
> Twitter: @farazath619 <https://twitter.com/farazath619>
> <http://wso2.com/signature>
>
>
>
> On Tue, Sep 5, 2017 at 10:16 PM, <shiv...@securelyshare.com> wrote:
>
>> Yes absolutely  is there any way or alternate way?
>>
>>
>>
>> *From:* Farasath Ahamed [mailto:farasa...@wso2.com]
>> *Sent:* 05 September 2017 22:14
>> *To:* shiv...@securelyshare.com; WSO2 Developers' List <dev@wso2.org>
>> *Subject:* Re: [Dev] Where can I find /token endpoint source code.
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Sep 5, 2017 at 10:06 PM, <shiv...@securelyshare.com> wrote:
>>
>> Hi Ahamed,
>>
>>
>>
>> Thank you for your response I found the configuration files. Is it
>> possible to change the /token context attribute to take a path variable in
>> /token and pass that to /oauth2/token. Eg.
>>
>>
>>
>> http://ws.apache.org/ns/synapse; name="_WSO2AMTokenAPI_"
>> context="/{domain}/token">
>>
>>
>>
>> And your ultimate target is to pass this particular parameter to the
>> password grant handler is it?
>>
>>
>>
>>
>>
>> Thank You,
>>
>> Shiva Kumar KR
>>
>>
>>
>> *From:* Farasath Ahamed [mailto:farasa...@wso2.com]
>> *Sent:* 05 September 2017 21:26
>> *To:* shiv...@securelyshare.com
>> *Cc:* WSO2 Developers' List <dev@wso2.org>
>> *Subject:* Re: [Dev] Where can I find /token endpoint source code.
>>
>>
>>
>> Hi Shiva,
>>
>>
>>
>> /token exposed is actually a proxy to /oauth2/token which is the actual
>> endpoint that handles your token request. Souce code for OAuth2 Token
>> Endpoint can be found in [1].
>>
>> You can find the proxy configuration for /token in
>> APIM_HOME/repository/deployment/server/synapse-configs/defau
>> lt/api/_TokenAPI_.xml
>>
>>
>>
>>
>>
>> [1] https://github.com/wso2-extensions/identity-inbound-auth
>> -oauth/blob/v5.3.4/components/org.wso2.carbon.identity.oauth
>> .endpoint/src/main/java/org/wso2/carbon/identity/oauth/
>> endpoint/token/OAuth2TokenEndpoint.java
>>
>>
>>
>>
>>
>> Thanks,
>>
>> Farasath
>>
>>
>> Farasath Ahamed
>>
>> Software Engineer, WSO2 Inc.; http://wso2.com
>>
>> Mobile: +94777603866
>>
>> Blog: blog.farazath.com
>>
>> Twitter: @farazath619 <https://twitter.com/farazath619>
>>
>> <http://wso2.com/signatur

Re: [Dev] Where can I find /token endpoint source code.

2017-09-05 Thread Farasath Ahamed

Hi Shiva,

Please use reply all including the dev list :) So that others will be able
to chip in with their ideas as well...

There is a small catch there. Even if you managed to pass the
tenantDomain as a query param to the token endpoint it will not reach your
extended password grant handler. The reason is this line of code in our
current implementation[1], which limits the password grant type to pass
username, password parameters only to the grant handler. We have fixed this
in master where we pass all the parameters sent in the token.

There is a small trick to get this working. You can write a grant handler
extending the password grant handler but register it as a custom grant
instead of grant_type=password, let's say you register it as
grant_type=custom1, then in the token request you can send the
tenantDomain as a parameter like below,

"grant_type=custom1=ddd=abc.com",

within the grant handler, you can access any parameter sent using,

 // extract request parameters
 RequestParameter[] parameters =
oAuthTokenReqMessageContext.getOauth2AccessTokenReqDTO().getRequestParameters();

All the details you need to implement a custom grant type are in [2] with
examples. Give it a try! :)


[1] https://github.com/wso2-support/identity-inbound-auth-
oauth/blob/support-5.3.3/components/org.wso2.carbon.
identity.oauth.endpoint/src/main/java/org/wso2/carbon/
identity/oauth/endpoint/token/OAuth2TokenEndpoint.java#L273-L275

[2]
https://docs.wso2.com/display/IS530/Writing+a+Custom+OAuth+2.0+Grant+Type


Thanks,
Farasath Ahamed
Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>



On Tue, Sep 5, 2017 at 10:16 PM, <shiv...@securelyshare.com> wrote:

> Yes absolutely  is there any way or alternate way?
>
>
>
> *From:* Farasath Ahamed [mailto:farasa...@wso2.com]
> *Sent:* 05 September 2017 22:14
> *To:* shiv...@securelyshare.com; WSO2 Developers' List <dev@wso2.org>
> *Subject:* Re: [Dev] Where can I find /token endpoint source code.
>
>
>
>
>
>
>
> On Tue, Sep 5, 2017 at 10:06 PM, <shiv...@securelyshare.com> wrote:
>
> Hi Ahamed,
>
>
>
> Thank you for your response I found the configuration files. Is it
> possible to change the /token context attribute to take a path variable in
> /token and pass that to /oauth2/token. Eg.
>
>
>
> http://ws.apache.org/ns/synapse; name="_WSO2AMTokenAPI_"
> context="/{domain}/token">
>
>
>
> And your ultimate target is to pass this particular parameter to the
> password grant handler is it?
>
>
>
>
>
> Thank You,
>
> Shiva Kumar KR
>
>
>
> *From:* Farasath Ahamed [mailto:farasa...@wso2.com]
> *Sent:* 05 September 2017 21:26
> *To:* shiv...@securelyshare.com
> *Cc:* WSO2 Developers' List <dev@wso2.org>
> *Subject:* Re: [Dev] Where can I find /token endpoint source code.
>
>
>
> Hi Shiva,
>
>
>
> /token exposed is actually a proxy to /oauth2/token which is the actual
> endpoint that handles your token request. Souce code for OAuth2 Token
> Endpoint can be found in [1].
>
> You can find the proxy configuration for /token in
> APIM_HOME/repository/deployment/server/synapse-configs/
> default/api/_TokenAPI_.xml
>
>
>
>
>
> [1] https://github.com/wso2-extensions/identity-inbound-auth
> -oauth/blob/v5.3.4/components/org.wso2.carbon.identity.
> oauth.endpoint/src/main/java/org/wso2/carbon/identity/
> oauth/endpoint/token/OAuth2TokenEndpoint.java
>
>
>
>
>
> Thanks,
>
> Farasath
>
>
> Farasath Ahamed
>
> Software Engineer, WSO2 Inc.; http://wso2.com
>
> Mobile: +94777603866
>
> Blog: blog.farazath.com
>
> Twitter: @farazath619 <https://twitter.com/farazath619>
>
> <http://wso2.com/signature>
>
>   <http://wso2.com/signature>
>
>   <http://wso2.com/signature>
>
>   <http://wso2.com/signature>
>
> On Tue, Sep 5, 2017 at 9:13 PM, <*shiv...@securelyshare.com*> wrote:
> <http://wso2.com/signature>
>
> Hi WSO2 team, <http://wso2.com/signature>
>
>   <http://wso2.com/signature>
>
> I want to know in which class /token url request is handled. It will be
> very helpful for me if any one suggest which class name and project.
> <http://wso2.com/signature>
>
>   <http://wso2.com/signature>
>
> Thank You, <http://wso2.com/signature>
>
> Shiva Kumar KR <http://wso2.com/signature>
>
>
> ___
> Dev mailing list
> *Dev@wso2.org*
> *http://wso2.org/cgi-bin/mailman/listinfo/dev* <http://wso2.com/signature>
>
>   <http://wso2.com/signature>
>
>   <http://wso2.com/signature>
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Where can I find /token endpoint source code.

2017-09-05 Thread Farasath Ahamed

On Tue, Sep 5, 2017 at 10:06 PM, <shiv...@securelyshare.com> wrote:

> Hi Ahamed,
>
>
>
> Thank you for your response I found the configuration files. Is it
> possible to change the /token context attribute to take a path variable in
> /token and pass that to /oauth2/token. Eg.
>
>
>
> http://ws.apache.org/ns/synapse; name="_WSO2AMTokenAPI_"
> context="/{domain}/token">
>

And your ultimate target is to pass this particular parameter to the
password grant handler is it?


>
>
> Thank You,
>
> Shiva Kumar KR
>
>
>
> *From:* Farasath Ahamed [mailto:farasa...@wso2.com]
> *Sent:* 05 September 2017 21:26
> *To:* shiv...@securelyshare.com
> *Cc:* WSO2 Developers' List <dev@wso2.org>
> *Subject:* Re: [Dev] Where can I find /token endpoint source code.
>
>
>
> Hi Shiva,
>
>
>
> /token exposed is actually a proxy to /oauth2/token which is the actual
> endpoint that handles your token request. Souce code for OAuth2 Token
> Endpoint can be found in [1].
>
> You can find the proxy configuration for /token in APIM_HOME/repository/
> deployment/server/synapse-configs/default/api/_TokenAPI_.xml
>
>
>
>
>
> [1] https://github.com/wso2-extensions/identity-inbound-
> auth-oauth/blob/v5.3.4/components/org.wso2.carbon.
> identity.oauth.endpoint/src/main/java/org/wso2/carbon/
> identity/oauth/endpoint/token/OAuth2TokenEndpoint.java
>
>
>
>
>
> Thanks,
>
> Farasath
>
>
> Farasath Ahamed
>
> Software Engineer, WSO2 Inc.; http://wso2.com
>
> Mobile: +94777603866
>
> Blog: blog.farazath.com
>
> Twitter: @farazath619 <https://twitter.com/farazath619>
>
> <http://wso2.com/signature>
>
>
>
>
>
>
>
> On Tue, Sep 5, 2017 at 9:13 PM, <shiv...@securelyshare.com> wrote:
>
> Hi WSO2 team,
>
>
>
> I want to know in which class /token url request is handled. It will be
> very helpful for me if any one suggest which class name and project.
>
>
>
> Thank You,
>
> Shiva Kumar KR
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Where can I find /token endpoint source code.

2017-09-05 Thread Farasath Ahamed

Hi Shiva,

/token exposed is actually a proxy to /oauth2/token which is the actual
endpoint that handles your token request. Souce code for OAuth2 Token
Endpoint can be found in [1].
You can find the proxy configuration for /token in
APIM_HOME/repository/deployment/server/synapse-configs/default/api/_TokenAPI_.xml

[1]
https://github.com/wso2-extensions/identity-inbound-auth-oauth/blob/v5.3.4/components/org.wso2.carbon.identity.oauth.endpoint/src/main/java/org/wso2/carbon/identity/oauth/endpoint/token/OAuth2TokenEndpoint.java

Thanks,
Farasath

Farasath Ahamed
Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>

On Tue, Sep 5, 2017 at 9:13 PM, <shiv...@securelyshare.com> wrote:

> Hi WSO2 team,
>
>
>
> I want to know in which class /token url request is handled. It will be
> very helpful for me if any one suggest which class name and project.
>
>
>
> Thank You,
>
> Shiva Kumar KR
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] how to obtain tenant domain from just clientid and client secret.

2017-09-05 Thread Farasath Ahamed

On Tue, Sep 5, 2017 at 12:52 PM, <shiv...@securelyshare.com> wrote:

> Hi Farasath,
>
>
>
> Thank you very much for your response. Advance sorry if this takes some
> time to read,
>
> I customizing the password grant type authentication which will call a my
> rest api to do authentication of users stored in our database server, *I
> cannot plug in it as a JDBC user store to wso2*. I just have to take
> username, password and tenant Id during authentication. My backend api
> expect tenantId for every request. Please see the details below of my
> requirements
>

By tenantId do you mean the tenantDomain of the authenticating user or the
app?
Can we assume these two (ie. App tenant Domain and User tenant domain) will
always be the same


>
> My API is also multi tenanted and it expects tenantId for every request.
>
> I use below url to obtain token.
>
> http://locahost:8280/token
>
> postbody -> grant_type=password=du...@gmail.com=dummy
>
> basicAuth -> clientId:clientsecret base64 encoded.
>
>
>
> I have to use du...@gmail.com@tenantdomain as username to get token
> because then only I can authenticate with my custom authentication
> mechanism.
>
>
>
> To obtain tenantId I am appending tenant domain name to username but I
> should avaoid this and use simply gmail username. I cannot use any user
> store that wso2 supports.
>
> I am using below code to extract tenantId from domain name which will
> extracted from username.
>
>
>
> Here -> username = du...@gmail.com@tenantdomain.com
>
>
>
> String username = oAuth2AccessTokenReqDTO.getResourceOwnerUsername();
>
> String userTenantDomain = MultitenantUtils.*getTenantDomain*(
> username);
>
> *int* tenantId = IdentityTenantUtil.*getTenantId*(userTenantDomain
> );
>
> String tenantAwareUserName = MultitenantUtils.
> *getTenantAwareUsername*(username);
>
>
>
> Please suggest if it’s possible to get tenantId without giving anything in
> username.
>
>
>
> Thank You,
>
> Shiva Kumar K R.
>
>
>
> *From:* Farasath Ahamed [mailto:farasa...@wso2.com]
> *Sent:* 05 September 2017 12:13
> *To:* shiv...@securelyshare.com
> *Cc:* WSO2 Developers' List <dev@wso2.org>
> *Subject:* Re: [Dev] how to obtain tenant domain from just clientid and
> client secret.
>
>
>
>
>
>
> Farasath Ahamed
>
> Software Engineer, WSO2 Inc.; http://wso2.com
>
> Mobile: +94777603866
>
> Blog: blog.farazath.com
>
> Twitter: @farazath619 <https://twitter.com/farazath619>
>
> <http://wso2.com/signature>
>
>
>
>
>
>
>
> On Mon, Sep 4, 2017 at 7:30 PM, <shiv...@securelyshare.com> wrote:
>
> Hi,
>
> I am using WSO2 api manager 2.1.0, and I am extending password grant type
> handler to customize few operations
>
> I tried to obtain tenant domain from OAuthAppDO from I got the below
> exception please help me.
>
>
>
> Here what is the tenantDomain you are trying obtain?
>
> Tenant domain to which the app belongs to or the tenant domain of the
> authenticated user?
>
>
>
> If it is Tenant domain to which the app belongs to, you can use util
> method[1]
>
>
>
> [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/util/
> OAuth2Util.java#L1290-L1316
>
>
>
>
>
> This is utility method I trying to get OauthAppDO from which I get
> AuthenticatedUser object and it’s tenantdomain. But it’s throwing exception.
>
>
>
> String tenantDomain = OAuthUtil.getAppInformationByC
> lientId(oAuth2AccessTokenReqDTO.getClientId()).getUser().get
> TenantDomain();
>
>
>
> ... 47 more
>
> [2017-09-04 18:55:59,723] ERROR - StandardWrapperValve Servlet.service()
> for servlet [OAuth2Endpoints] in context with path [/oauth2] threw exception
>
> java.lang.RuntimeException: org.apache.cxf.interceptor.Fault:
> org.wso2.carbon.identity.oauth.OAuthUtil.getAppInformationBy
> ClientId(Ljava/lang/String;)Lorg/wso2/carbon/identity/
> oauth/dao/OAuthAppDO;
>
> at org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserv
> er.onMessage(AbstractFaultChainInitiatorObserver.java:116)
>
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(Phase
> InterceptorChain.java:336)
>
> at org.apache.cxf.transport.ChainInitiationObserver.onMessage(C
> hainInitiationObserver.java:121)
>
> at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke
> (AbstractHTTPDestination.java:249)
>
>

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

2017-09-05 Thread Farasath Ahamed

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 <hasin...@wso2.com>
> 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.

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 <is...@wso2.com>
>> 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 <is...@wso2.com>
>>>> 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.
>>>>>>
>>>>>
>>>>> Is that working correctly?. I think HEAD operation returns 200 OK for
>>>>> any endpoint starting with https://localhost:9443.
>>>>>
>>>>
>>>> How can that happen ?
>>>>
>>> Because carbon redirects invalid urls to main page.
>>>
>>
> This is because the http client follows the redirects by default. If we
> disable following redirects at the client this check should be possible,
> and it will return a 302 if identity mgt web app doesn't exist.
>
>>
>>>
>>> We call head on the URL right. Anyway, if it's not working we should
>>>> fix.
>>>>
>>>>>
>>>>> Thanks
>>>>> Isura.
>>>>>
>>>>>
>>>>>>> On Fri, Aug 18, 2017 at 11:54 AM, Farasath Ahamed <
>>>>>>> farasa...@wso2.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> There is another complication here. We are not honouring the
>>>>>>>> hostname verification settings set by Kernel when doing the backend 
>>>>>>>> call.
>>&

Re: [Dev] how to obtain tenant domain from just clientid and client secret.

2017-09-05 Thread Farasath Ahamed

Farasath Ahamed
Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>



On Mon, Sep 4, 2017 at 7:30 PM, <shiv...@securelyshare.com> wrote:

> Hi,
>
> I am using WSO2 api manager 2.1.0, and I am extending password grant type
> handler to customize few operations
>
> I tried to obtain tenant domain from OAuthAppDO from I got the below
> exception please help me.
>

Here what is the tenantDomain you are trying obtain?
Tenant domain to which the app belongs to or the tenant domain of the
authenticated user?

If it is Tenant domain to which the app belongs to, you can use util
method[1]

[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/util/OAuth2Util.java#L1290-L1316


>
>
> This is utility method I trying to get OauthAppDO from which I get
> AuthenticatedUser object and it’s tenantdomain. But it’s throwing exception.
>
>
>
> String tenantDomain = OAuthUtil.getAppInformationByClientId(
> oAuth2AccessTokenReqDTO.getClientId()).getUser().getTenantDomain();
>
>
>
> ... 47 more
>
> [2017-09-04 18:55:59,723] ERROR - StandardWrapperValve Servlet.service()
> for servlet [OAuth2Endpoints] in context with path [/oauth2] threw exception
>
> java.lang.RuntimeException: org.apache.cxf.interceptor.Fault:
> org.wso2.carbon.identity.oauth.OAuthUtil.getAppInformationByClientId(
> Ljava/lang/String;)Lorg/wso2/carbon/identity/oauth/dao/OAuthAppDO;
>
> at org.apache.cxf.interceptor.AbstractFaultChainInitiatorObs
> erver.onMessage(AbstractFaultChainInitiatorObserver.java:116)
>
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(
> PhaseInterceptorChain.java:336)
>
> at org.apache.cxf.transport.ChainInitiationObserver.onMessage(
> ChainInitiationObserver.java:121)
>
> at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(
> AbstractHTTPDestination.java:249)
>
> at org.apache.cxf.transport.servlet.ServletController.
> invokeDestination(ServletController.java:248)
>
> at org.apache.cxf.transport.servlet.ServletController.
> invoke(ServletController.java:222)
>
> at org.apache.cxf.transport.servlet.ServletController.
> invoke(ServletController.java:153)
>
> at org.apache.cxf.transport.servlet.CXFNonSpringServlet.
> invoke(CXFNonSpringServlet.java:171)
>
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.
> handleRequest(AbstractHTTPServlet.java:289)
>
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.
> doPost(AbstractHTTPServlet.java:209)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:650)
>
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.
> service(AbstractHTTPServlet.java:265)
>
> at org.apache.catalina.core.ApplicationFilterChain.
> internalDoFilter(ApplicationFilterChain.java:303)
>
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(
> ApplicationFilterChain.java:208)
>
> at org.apache.tomcat.websocket.server.WsFilter.doFilter(
> WsFilter.java:52)
>
> at org.apache.catalina.core.ApplicationFilterChain.
> internalDoFilter(ApplicationFilterChain.java:241)
>
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(
> ApplicationFilterChain.java:208)
>
> at org.apache.catalina.filters.HttpHeaderSecurityFilter.doFilter(
> HttpHeaderSecurityFilter.java:120)
>
> at org.apache.catalina.core.ApplicationFilterChain.
> internalDoFilter(ApplicationFilterChain.java:241)
>
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(
> ApplicationFilterChain.java:208)
>
> at org.apache.catalina.core.StandardWrapperValve.invoke(
> StandardWrapperValve.java:218)
>
> at org.apache.catalina.core.StandardContextValve.invoke(
> StandardContextValve.java:122)
>
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(
> AuthenticatorBase.java:505)
>
> at org.apache.catalina.core.StandardHostValve.invoke(
> StandardHostValve.java:169)
>
> at org.apache.catalina.valves.ErrorReportValve.invoke(
> ErrorReportValve.java:103)
>
> at org.wso2.carbon.tomcat.ext.valves.CompositeValve.
> continueInvocation(CompositeValve.java:99)
>
> at org.wso2.carbon.tomcat.ext.valves.CarbonTomcatValve$1.
> invoke(CarbonTomcatValve.java:47)
>
> at org.wso2.carbon.webapp.mgt.TenantLazyLoaderValve.invoke(
> TenantLazyLoaderValve.java:57)
>
> at org.wso2.carbon.event.r

Re: [Dev] Change token url in WSO2 API Manager

2017-09-05 Thread Farasath Ahamed

Hi Shiva,

Any particular reason why you want to change this URL?
Just trying to understand your requirement see if there's any alternate
approach without changing the URL etc.


Thanks,
Farasath

Farasath Ahamed
Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>



On Tue, Sep 5, 2017 at 11:19 AM, <shiv...@securelyshare.com> wrote:

> Hi Wso2 team,
>
>
>
> Please can you suggest any ways to change default token generation url,
> http://:8280/token  to http://:8280/t/<
> tenant-domain>/token.
>
> For eg.
>
> Default token generation is http://wso2.com:8280/token
>
> I want – http://wso2.com:8280/t/securelyshare.com/token
>
>
>
> How can I achieve this, thanks in advance.
>
>
>
> Thank You,
>
> Shiva Kumar KR
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Should we trim usernames when authenticating at UserStore level?

2017-09-04 Thread Farasath Ahamed

Created [1] to track this

[1] https://github.com/wso2/product-is/issues/1352

Farasath Ahamed
Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>



On Sun, Sep 3, 2017 at 3:54 PM, Johann Nallathamby <joh...@wso2.com> wrote:

> +1
>
> It should be consistent and I also don't think we should be trimming.
>
> On Sun, Sep 3, 2017 at 12:40 PM, Farasath Ahamed <farasa...@wso2.com>
> wrote:
>
>> Hi Devs,
>>
>> Noticed that we trim the username when performing authentication in LDAP
>> and AD Userstore Managers[1]. But we do not do trim the username in
>> JDBCUserStoreManager[2]?
>>
>> IMO we should have the similar behaviour for all the user stores, ie.
>> either we trim the username in each of them or we don't trim in any of them?
>>
>> On the other hand, I think we shouldn't trim the username at all since it
>> leads to issue like[3], where the authentication was successful because of
>> trimming the spaces silently but claims retrieval etc. fails due to the
>> incorrect username with extra spaces.
>>
>> Appreciate your thoughts!
>>
>>
>> [1] https://github.com/wso2/carbon-kernel/blob/4.4.x/core/or
>> g.wso2.carbon.user.core/src/main/java/org/wso2/carbon/user/
>> core/ldap/ReadOnlyLDAPUserStoreManager.java#L357
>>
>> [2] https://github.com/wso2/carbon-kernel/blob/f551d3530300a
>> 43ca1afc2a56d62be34f2d72320/core/org.wso2.carbon.user.
>> core/src/main/java/org/wso2/carbon/user/core/jdbc/JDBCUser
>> StoreManager.java#L1152-L1235
>>
>> [3] https://wso2.org/jira/browse/IDENTITY-5864
>>
>>
>> Thanks,
>> Farasath Ahamed
>> Software Engineer, WSO2 Inc.; http://wso2.com
>> Mobile: +94777603866
>> Blog: blog.farazath.com
>> Twitter: @farazath619 <https://twitter.com/farazath619>
>> <http://wso2.com/signature>
>>
>>
>>
>
>
> --
> Thanks & Regards,
>
> *Johann Dilantha Nallathamby*
> Senior Lead Solutions Engineer
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile - *+9476950*
> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] Should we trim usernames when authenticating at UserStore level?

2017-09-03 Thread Farasath Ahamed

Hi Devs,

Noticed that we trim the username when performing authentication in LDAP
and AD Userstore Managers[1]. But we do not do trim the username in
JDBCUserStoreManager[2]?

IMO we should have the similar behaviour for all the user stores, ie.
either we trim the username in each of them or we don't trim in any of them?

On the other hand, I think we shouldn't trim the username at all since it
leads to issue like[3], where the authentication was successful because of
trimming the spaces silently but claims retrieval etc. fails due to the
incorrect username with extra spaces.

Appreciate your thoughts!


[1]
https://github.com/wso2/carbon-kernel/blob/4.4.x/core/org.wso2.carbon.user.core/src/main/java/org/wso2/carbon/user/core/ldap/ReadOnlyLDAPUserStoreManager.java#L357

[2]
https://github.com/wso2/carbon-kernel/blob/f551d3530300a43ca1afc2a56d62be34f2d72320/core/org.wso2.carbon.user.core/src/main/java/org/wso2/carbon/user/core/jdbc/JDBCUserStoreManager.java#L1152-L1235

[3] https://wso2.org/jira/browse/IDENTITY-5864


Thanks,
Farasath Ahamed
Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [IS] [SCIM] Why Can't We Enable Both SCIM1 and SCIM2 at the Same Time?

2017-08-30 Thread Farasath Ahamed

On Wednesday, August 30, 2017, Thilina Madumal <thilina...@wso2.com> wrote:

>
> Hi all,
>
> While I was trying to fix IDENTITY-6315
> <https://wso2.org/jira/browse/IDENTITY-6315> I got to know that we can't
> enable both SCIM1 and SCIM2 at the same time in WSO2 Identity Server.
> Is it because of this specific issue or is there any other reasons?
>

I don't see a reason as to why we can't have both SCIM implementations
enabled at the same time since each of them expose a seperate web app.

>From outside its just like having two APIs to do user operations. Did you
face any issues when enabling both?


>
> Thanks & Regards,
>
Thilina.
>
> --
> *Thilina Madumal*
> *Software Engineer | **WSO2*
> Email: thilina...@wso2.com
> <javascript:_e(%7B%7D,'cvml','thilina...@wso2.com');>
> Mobile: *+ <+94%2077%20767%201807>94 774553167*
> Web:  <http://goog_716986954>http://wso2.com
>
> <http://wso2.com/signature>
>
>

-- 
Farasath Ahamed
Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Audience(aud) value in OpenID Connect ID Token vs Token Introspection response

2017-08-23 Thread Farasath Ahamed

Farasath Ahamed
Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>



On Wed, Aug 23, 2017 at 1:58 PM, Gayan Gunawardana <ga...@wso2.com> wrote:

>
>
> On Wed, Aug 23, 2017 at 1:46 PM, Asela Pathberiya <as...@wso2.com> wrote:
>
>>
>>
>> On Tue, Aug 22, 2017 at 11:32 AM, Gayan Gunawardana <ga...@wso2.com>
>> wrote:
>>
>>> According to OpenID connect specification [1] "aud" value is client id
>>> with identifiers for other audiences.
>>>
>>>  {
>>>"iss": "https://server.example.com;,
>>>"sub": "24400320",
>>>"aud": "s6BhdRkqt3",
>>>"nonce": "n-0S6_WzA2Mj",
>>>"exp": 1311281970,
>>>"iat": 1311280970,
>>>"auth_time": 1311280969,
>>>"acr": "urn:mace:incommon:iap:silver"
>>>   }
>>>
>>> But in token introspection "aud" value is more like service provider URL
>>> with identifiers for other audiences.
>>>
>>
>> Where is it mentioned that it must be the SP URL.  I guess it must be
>> some kind of identification such as client id.  Isn't it ?
>>
> Yes no it is not a URL but kind of URI which represent service provider.
> According to offline chat had with Ruwan in Oauth/OpenID connect
> configuration there should be a way to configure Audiences like in SAML.
>

We do have a way to do this for OpenID Connect via identity.xml from IS
5.2.0. We did this so that our id_token could be used as a JWT Bearer
Grant. JWT Bearer grant requires the authorization server's token endpoint
or it alias to be included as a audience.



org.wso2.carbon.identity.openidconnect.DefaultIDTokenBuilder
SHA256withRSA


**






But of course that would be a global value. So we might have to do an
improvement to define that per Service Provider





>
>>
>>>
>>>  {
>>>   "active": true,
>>>   "client_id": "l238j323ds-23ij4",
>>>   "username": "jdoe",
>>>   "scope": "read write dolphin",
>>>   "sub": "Z5O3upPC88QrAjx00dis",
>>>   "aud": "https://protected.example.net/resource;,
>>>   "iss": "https://server.example.com/;,
>>>   "exp": 1419356238,
>>>   "iat": 1419350238,
>>>   "extension_field": "twenty-seven"
>>>  }
>>>
>>> Can we have different Audience values for token introspection response
>>> and ID Token ? If not we can have both as Audience values.
>>>
>>> [1] http://openid.net/specs/openid-connect-core-1_0.html#IDToken
>>> [2] https://tools.ietf.org/html/rfc7662#section-2.2
>>>
>>> Thanks,
>>> Gayan
>>>
>>> --
>>> Gayan Gunawardana
>>> Senior Software Engineer; WSO2 Inc.; http://wso2.com/
>>> Email: ga...@wso2.com
>>> Mobile: +94 (71) 8020933
>>>
>>
>>
>>
>> --
>> Thanks & Regards,
>> Asela
>>
>> ATL
>> Mobile : +94 777 625 933 <+94%2077%20762%205933>
>>  +358 449 228 979
>>
>> http://soasecurity.org/
>> http://xacmlinfo.org/
>>
>
>
>
> --
> 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

Re: [Dev] Improve Default Claim Handler logic

2017-08-21 Thread Farasath Ahamed

Farasath Ahamed
Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>



On Mon, Aug 21, 2017 at 9:35 AM, Hasanthi Purnima Dissanayake <
hasan...@wso2.com> wrote:

> Hi Farasath,
>
> The logic behind returning claims in 'oidc' is based on the intersection
> of both sp requested claims and the registry defined claims for the scope.
> So in order to return a specific claims it should define in the registry
> and it should define as a requested claims.
>
> 2. Improve the fix[2] to return all claims for *openid *flow only when
>> service provider has no requested claims.
>>
>>  So why do we need to return all the claims for openid flow when the SP
> has no requested claims?
>

I think there is a small confusing here. In the our current implementation
we are returing all the claims for *openid *(not *openidconnect*) request
type[1]. So I wanted to improve the handler logic while maintaining
backward compatibility for *openid* relying parties.


[1]
https://github.com/wso2/carbon-identity-framework/blob/77b83f1d2ca172366a86476395da3062c56c4fd6/components/authentication-framework/org.wso2.carbon.identity.application.authentication.framework/src/main/java/org/wso2/carbon/identity/application/authentication/framework/handler/claims/impl/DefaultClaimHandler.java#L422



>
> Thanks,
>
> Hasanthi Dissanayake
>
> Software Engineer | WSO2
>
> E: hasan...@wso2.com
> M :0718407133| http://wso2.com <http://wso2.com/>
>
> On Mon, Aug 21, 2017 at 9:11 AM, Rushmin Fernando <rush...@wso2.com>
> wrote:
>
>> yes, we should get rid of unwanted processing.
>>
>> IMO we should honour the configured requested claims in the service
>> provider. But I'm not aware whether there was a need to send all the claims
>> for open id.
>>
>>
>>
>> On Sat, Aug 19, 2017 at 7:48 PM, Farasath Ahamed <farasa...@wso2.com>
>> wrote:
>>
>>> Hi All,
>>>
>>> In the current implementation of the DefaultClaimHandler[1] claim
>>> handling logic involves the below steps when retrieving claims for local
>>> and federated scenarios,
>>>
>>> 1. Loading local claims and claims mappings
>>> 2. Loading all non-empty claims of the user
>>>
>>> #1 involves several DB calls where as step #2 results in a call to the
>>> user store which means either a DB call or LDAP/AD call depending on the
>>> user store configured.
>>>
>>> Here are few shortcoming I noticed,
>>>
>>>1. If a service provider has configured no requested claims, we
>>>simply return an empty map of claims after going through the whole 
>>> process
>>>#1 and #2.
>>>2. For authentication involved with flows like OAuth which do not
>>>involve claims going through this claims handling logic doesn't make any
>>>sense.
>>>
>>>
>>> To give an idea of the performance impact, An authentication request
>>> coming into the Authentication Framework takes about 950ms to complete. Of
>>> this around 550ms is spent on handling claims (that's close to ~60%). So
>>> for an OAuth flow with authorization code or implicit flow, this is a
>>> performance hit.
>>>
>>> I initially did a fix for this[2], by returning an empty map of claims
>>> if the there were no requested claims. But this doesn't seem to work since
>>> we seem to return all available claims for *openid *flow[3].
>>>
>>> Do we have a specific reason for return all available claims in the
>>> openid flow? Shouldn't we honour service provider requested claims when
>>> sending out user claims out of the framework?
>>>
>>>
>>> I have a few improvements in my mind to overcome the problem,
>>>
>>> 1. Specifically, check for the *oauth *request type and stop executing
>>> claim handling logic.
>>> 2. Improve the fix[2] to return all claims for *openid *flow only when
>>> service provider has no requested claims.
>>>
>>> Do you see any complexities that could arise with the suggested
>>> improvements?
>>>
>>>
>>> [1] https://github.com/wso2/carbon-identity-framework/blob/m
>>> aster/components/authentication-framework/org.wso2.carbon.id
>>> entity.application.authentication.framework/src/main/java/or
>>> g/wso2/carbon/identity/application/authentication/framework/
>>> handler/claims/impl/DefaultClaimHandler.java
>>>
>>> [2] https://git

Re: [Dev] Missing Attributes in Token Introspection Response

2017-08-21 Thread Farasath Ahamed

On Mon, Aug 21, 2017 at 1:23 PM, Gayan Gunawardana  wrote:

>
>
> On Mon, Aug 21, 2017 at 1:21 PM, Ruwan Abeykoon  wrote:
>
>> Hi All,
>> I think we need to add them in introspection result, since they were
>> anyway present in AuthenticationResponse inside JWT.
>>
>> @Gayan,
>> How about the acr, amr ?
>>
> +1 we can add them too.
>

Can we also consider providing an extension point to decide attributes that
go into the introspection response?


>
>> Cheers,
>> Ruwan
>>
>> On Mon, Aug 21, 2017 at 11:08 AM, Gayan Gunawardana 
>> wrote:
>>
>>> Hi Indunil,
>>>
>>> Form token introspection response I can get below attributes.
>>>
>>> {"scope":"openid","active":true,"token_type":"Bearer","exp":
>>> 1503061170,"iat":1503057570,"client_id":"oRbEK6KkycbSLGxt3JH
>>> ciaitPzoa","username":"admin@carbon.super"}
>>>
>>> But some of optional attributes are not included in introspection
>>> response
>>>
>>>sub
>>>   OPTIONAL.  Subject of the token, as defined in JWT [RFC7519 
>>> ].
>>>   Usually a machine-readable identifier of the resource owner who
>>>   authorized this token.
>>>
>>>aud
>>>   OPTIONAL.  Service-specific string identifier or list of string
>>>   identifiers representing the intended audience for this token, as
>>>   defined in JWT [RFC7519 ].
>>>
>>>iss
>>>   OPTIONAL.  String representing the issuer of this token, as
>>>   defined in JWT [RFC7519 ].
>>>
>>> Do we have any limitation to support above attributes ?
>>>
>>>
>>> [1] https://tools.ietf.org/html/rfc7662
>>>
>>> Thanks,
>>> Gayan
>>> --
>>> Gayan Gunawardana
>>> Senior Software Engineer; WSO2 Inc.; http://wso2.com/
>>> Email: ga...@wso2.com
>>> Mobile: +94 (71) 8020933
>>>
>>
>>
>>
>>
>>
>
>
> --
> 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
>
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] Improve Default Claim Handler logic

2017-08-19 Thread Farasath Ahamed

Hi All,

In the current implementation of the DefaultClaimHandler[1] claim handling
logic involves the below steps when retrieving claims for local and
federated scenarios,

1. Loading local claims and claims mappings
2. Loading all non-empty claims of the user

#1 involves several DB calls where as step #2 results in a call to the user
store which means either a DB call or LDAP/AD call depending on the user
store configured.

Here are few shortcoming I noticed,

   1. If a service provider has configured no requested claims, we simply
   return an empty map of claims after going through the whole process #1 and
   #2.
   2. For authentication involved with flows like OAuth which do not
   involve claims going through this claims handling logic doesn't make any
   sense.


To give an idea of the performance impact, An authentication request coming
into the Authentication Framework takes about 950ms to complete. Of this
around 550ms is spent on handling claims (that's close to ~60%). So for an
OAuth flow with authorization code or implicit flow, this is a performance
hit.

I initially did a fix for this[2], by returning an empty map of claims if
the there were no requested claims. But this doesn't seem to work since we
seem to return all available claims for *openid *flow[3].

Do we have a specific reason for return all available claims in the openid
flow? Shouldn't we honour service provider requested claims when sending
out user claims out of the framework?


I have a few improvements in my mind to overcome the problem,

1. Specifically, check for the *oauth *request type and stop executing
claim handling logic.
2. Improve the fix[2] to return all claims for *openid *flow only when
service provider has no requested claims.

Do you see any complexities that could arise with the suggested
improvements?


[1] https://github.com/wso2/carbon-identity-framework/
blob/master/components/authentication-framework/org.wso2.carbon.identity.
application.authentication.framework/src/main/java/org/wso2/carbon/identity/
application/authentication/framework/handler/claims/impl/
DefaultClaimHandler.java

[2] https://github.com/wso2/carbon-identity-framework/pull/961

[3] https://github.com/wso2/carbon-identity-framework/
blob/master/components/authentication-framework/org.wso2.carbon.identity.
application.authentication.framework/src/main/java/org/wso2/carbon/identity/
application/authentication/framework/handler/claims/impl/
DefaultClaimHandler.java#L422


Thanks,
Farasath Ahamed
Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

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

2017-08-18 Thread Farasath Ahamed

I am okay with doing the http calls to ensure we dont have any broken
links.

But if anything goes wrong because of the http calls (hostname verification
 error or any other exception) it shouldn't break the login page.



On Friday, August 18, 2017, Isura Karunaratne <is...@wso2.com> wrote:

> Hi Malithi,
>
> On Fri, Aug 18, 2017 at 3:41 PM, Malithi Edirisinghe <malit...@wso2.com
> <javascript:_e(%7B%7D,'cvml','malit...@wso2.com');>> wrote:
>
>>
>>
>> On Fri, Aug 18, 2017 at 12:31 PM, Nuwandi Wickramasinghe <
>> nuwan...@wso2.com <javascript:_e(%7B%7D,'cvml','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.
>>
>
> Is that working correctly?. I think HEAD operation returns 200 OK for any
> endpoint starting with https://localhost:9443.
>
> Thanks
> Isura.
>
>
>>> On Fri, Aug 18, 2017 at 11:54 AM, Farasath Ahamed <farasa...@wso2.com
>>> <javascript:_e(%7B%7D,'cvml','farasa...@wso2.com');>> wrote:
>>>
>>>>
>>>> There is another complication here. We are not honouring the hostname
>>>> verification settings set by Kernel when doing the backend call.
>>>> Ideally, we should be using the common-http client if we are doing any
>>>> backend https calls.
>>>>
>>>>
>>>> Farasath Ahamed
>>>> Software Engineer, WSO2 Inc.; http://wso2.com
>>>> Mobile: +94777603866
>>>> Blog: blog.farazath.com
>>>> Twitter: @farazath619 <https://twitter.com/farazath619>
>>>> <http://wso2.com/signature>
>>>>
>>>>
>>>>
>>>> On Fri, Aug 18, 2017 at 11:45 AM, Gayan Gunawardana <ga...@wso2.com
>>>> <javascript:_e(%7B%7D,'cvml','ga...@wso2.com');>> wrote:
>>>>
>>>>> In IS 5.4.0-m2 SSO login page we can see couple of hyper links for
>>>>> Forgot Password, Forgot Username, Register Now as below.
>>>>>
>>>>>
>>>>> 
>>>>> Actually how it renders is
>>>>>
>>>>>  <%
>>>>> url = new URL(identityMgtEndpointContext +
>>>>> "/recoverpassword.do?callback=" + Encode.forHtmlAttribute
>>>>> (urlEncodedURL));
>>>>> httpURLConnection = (HttpURLConnection)
>>>>> url.openConnection();
>>>>> httpURLConnection.setRequestMethod("HEAD");
>>>>> httpURLConnection.connect();
>>>>> if (httpURLConnection.getResponseCode() ==
>>>>> HttpURLConnection.HTTP_OK) {
>>>>> %>
>>>>> Forgot Password
>>>>> 
>>>>> 
>>>>> <%
>>>>> }
>>>>>
>>>>> So every time when user goes to SSO login page need to send 3 http
>>>>> requests to render 3 hyper links. Also if any of API raises back-end
>>>>> exception, bad stack trace will be printed as below.
>>>>>
>>>>> WARN {org.apache.cxf.phase.PhaseInterceptorChain} -  Application {
>>>>> http://endpoint.recovery.identity.carbon.wso2.org/}ClaimsApi has
>>>>> thrown exception, unwinding now
>>>>> org.apache.cxf.interceptor.Fault
>>>>>
>>>>>  Is there a better way to handle this situation ?
>>>>>
>>>>> Thanks,
>>>>> Gayan
>>>>>
>>>>> --
>>>>> Gayan Gunawardana
>>>>> Senior Software Engineer; WSO2 Inc.; http://wso2.com/
>>>>> Email: ga...@wso2.com <javascript:_e(%7B%7D,'cvml','ga...@wso2.com');>
>>>>> Mobile: +94 (71) 8020933
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> Best Regards,
>>>
>>> Nuwandi Wickramasinghe
>>>
>>> Software Engineer
>>>
>>> WSO2 Inc.
>>>
>>> Web : http://wso2.com
>>>
>>> Mobile : 0719214873
>>>
>>
>>
>>
>> --
>>
>> *Malithi Edirisinghe*
>> Associate Technical Lead
>> WSO2 Inc.
>>
>> Mobile : +94 (0) 718176807
>> malit...@wso2.com <javascript:_e(%7B%7D,'cvml','malit...@wso2.com');>
>>
>
>
>
> --
>
> *Isura Dilhara Karunaratne*
> Associate Technical Lead | WSO2
> Email: is...@wso2.com <javascript:_e(%7B%7D,'cvml','is...@wso2.com');>
> Mob : +94 772 254 810
> Blog : http://isurad.blogspot.com/
>
>
>
>

-- 
Farasath Ahamed
Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>
<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

1 2 3 >

1 - 100 of 245 matches

Mail list logo