Re: [Architecture] [IS] User Challenge question Internationalization

[Farasath Ahamed]

Hi,

In the current implementation, challenge questions are persisted to the
registry as registry resource properties as shown below.


I had a look at the discussion[1] on how persisting email templates for
different locale should be done. I am planning to follow a similar approach
in storing challenge questions for different locale. The idea explained in
[1] is to store the template/question as a registry resource rather than as
a registry property. So I will be following a structure similar to shown
below to store the challenge questions.


​
So each question will be stored following a
*/system/config/challenge-questions///
*convention as shown above. The first step is to reuse most of the email
templates registry persistence code and make it generic (provide an
interface) to retrieve any registry resource(eg: email templates, challenge
questions, ) based on locale. The next step is to abstract the retrieval of
resources logic to support retrieval of resources from a DB, API etc.


[1] http://mail.wso2.org/mailarchive/architecture/2015-May/020188.html

Thanks,
Farasath Ahamed
Software Engineer,
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS] Regenerating client secret/key and revoking an oauth app in OAuth 2.0 implementation

[Farasath Ahamed]

Hi,

Since client_id is simply an identifier for the OAuth application, is it
really required to regenerate the client_id when the client_secret is
compromised?

Isn't it be similar to a situation where we are changing our username and
password because our password was compromised?



Farasath Ahamed
Software Engineer,
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware


Email: farasa...@wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>

On Fri, Jun 3, 2016 at 11:32 AM, Harsha Thirimanna <hars...@wso2.com> wrote:

> Hi Farasath,
>
> In that case, we have to create a new application if some one wants to
> reset the consumer key. That will not be a good experience to the user and
> specification also not specifically saying that only we should revoke
> consumer key or both.
>
> An authorization server may revoke a client's secret in order to
>prevent abuse of a revealed secret.
>
>
> Note: This measure will immediately invalidate any authorization
>"code" or refresh token issued to the respective client.  This might
>unintentionally impact client identifiers and secrets used across
>multiple deployments of a particular native or web application.
>
>
>
> *Harsha Thirimanna*
> Associate Tech Lead; WSO2, Inc.; http://wso2.com
> * <http://www.apache.org/>*
> *email: **hars...@wso2.com* <az...@wso2.com>* cell: +94 71 5186770 *
> *twitter: **http://twitter.com/ <http://twitter.com/afkham_azeez>*
> *harshathirimannlinked-in: **http:
> <http://lk.linkedin.com/in/afkhamazeez>**//www.linkedin.com/pub/harsha-thirimanna/10/ab8/122
> <http://www.linkedin.com/pub/harsha-thirimanna/10/ab8/122>*
>
> *Lean . Enterprise . Middleware*
>
>
> On Fri, Jun 3, 2016 at 11:11 AM, Farasath Ahamed <farasa...@wso2.com>
> wrote:
>
>> Hi Indunil,
>>
>> In a case of client_secret being revealed wouldn't it be sufficient only
>> to regenerate the client_key without regenerating the consumer key? In
>> Google API console I have noticed that you only have the option to reset
>> the client secret of an OAuth application. If you want to regenerate both
>> client_id and client_secret you simply delete the app and create a new one.
>>
>>
>> Thanks,
>> Farasath Ahamed
>> Software Engineer,
>> WSO2 Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>>
>> Email: farasa...@wso2.com
>> Mobile: +94777603866
>> Blog: blog.farazath.com
>> Twitter: @farazath619 <https://twitter.com/farazath619>
>>
>> On Fri, Jun 3, 2016 at 10:21 AM, Indunil Upeksha Rathnayake <
>> indu...@wso2.com> wrote:
>>
>>> Hi,
>>> I am working on [1] for implementing regeneration of client secret/key
>>> of an oauth app and revocation of an oauth app for the next milestone
>>> release of Identity Server. Appreciate your feedbacks on the following
>>> approaches I have taken.
>>>
>>> A trusted client would need to update the client secret/key, in order to
>>> prevent the abuse of revealed client secret/key. So for addressing that, I
>>> am working on adding two options as *Regenerate Client Secret* and 
>>> *Regenerate
>>> Consumer Key* for oauth applications in IS. After a client secret/key
>>> get regenerated, that will immediately invalidate any active authorization
>>> code, access token or refresh token, issued to the respective client.
>>>
>>>
>>>
>>> *Will it be necessary to add two options for revoking client secret and
>>> key or better to go for a different approach?*
>>> And apart from that planning for the implementation of *Revoking an
>>> oauth app*. In there the oauth app will be revoked and that also will
>>> immediately invalidate any active authorization code, access token or
>>> refresh token, issued to the respective client. In order to activate the
>>> oauth app again, need to regenerate the client secret.
>>>
>>>
>>> *In there to activate the app, better to regenerate "both client key and
>>> secret" or "either client key or secret"?*
>>>
>>> Really value your ideas/suggestions on improving this feature.
>>>
>>> [1] https://redmine.wso2.com/issues/2135
>>>
>>> Thanks and Regards
>>> --
>>> Indunil Upeksha Rathnayake
>>> Software Engineer | WSO2 Inc
>>> Emailindu...@wso2.com
>>>
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS] Regenerating client secret/key and revoking an oauth app in OAuth 2.0 implementation

[Farasath Ahamed]

Hi Indunil,

In a case of client_secret being revealed wouldn't it be sufficient only to
regenerate the client_key without regenerating the consumer key? In Google
API console I have noticed that you only have the option to reset the
client secret of an OAuth application. If you want to regenerate both
client_id and client_secret you simply delete the app and create a new one.


Thanks,
Farasath Ahamed
Software Engineer,
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware


Email: farasa...@wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>

On Fri, Jun 3, 2016 at 10:21 AM, Indunil Upeksha Rathnayake <
indu...@wso2.com> wrote:

> Hi,
> I am working on [1] for implementing regeneration of client secret/key of
> an oauth app and revocation of an oauth app for the next milestone release
> of Identity Server. Appreciate your feedbacks on the following approaches I
> have taken.
>
> A trusted client would need to update the client secret/key, in order to
> prevent the abuse of revealed client secret/key. So for addressing that, I
> am working on adding two options as *Regenerate Client Secret* and *Regenerate
> Consumer Key* for oauth applications in IS. After a client secret/key get
> regenerated, that will immediately invalidate any active authorization
> code, access token or refresh token, issued to the respective client.
>
>
>
> *Will it be necessary to add two options for revoking client secret and
> key or better to go for a different approach?*
> And apart from that planning for the implementation of *Revoking an oauth
> app*. In there the oauth app will be revoked and that also will
> immediately invalidate any active authorization code, access token or
> refresh token, issued to the respective client. In order to activate the
> oauth app again, need to regenerate the client secret.
>
>
> *In there to activate the app, better to regenerate "both client key and
> secret" or "either client key or secret"?*
>
> Really value your ideas/suggestions on improving this feature.
>
> [1] https://redmine.wso2.com/issues/2135
>
> Thanks and Regards
> --
> Indunil Upeksha Rathnayake
> Software Engineer | WSO2 Inc
> Emailindu...@wso2.com
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS] User Challenge question Internationalization

[Farasath Ahamed]

Hi Kasun,

"isPromoteQuestion" property is no longer used in our current
implementation. Therefore, we can get rid of the property and straight away
persist the challenge question as a registry resource.

Thanks,

Farasath Ahamed
Software Engineer,
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware


Email: farasa...@wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>

On Sat, Jun 4, 2016 at 12:26 AM, Kasun Bandara <kas...@wso2.com> wrote:

> Hi Farasath,
>
> +1 for storing the content of the questions as the registry resource
> values. But how are you planning to store the boolean values such as "
> *isPromoteQuestion*" ?. I think it's better to keep that sort of data as
> a property value, so the retrieval process will be easy. WDYT ?
>
> Thanks,
> Kasun.
>
> On Sat, Jun 4, 2016 at 12:16 AM, Farasath Ahamed <farasa...@wso2.com>
> wrote:
>
>> Hi,
>>
>> In the current implementation, challenge questions are persisted to the
>> registry as registry resource properties as shown below.
>>
>>
>> I had a look at the discussion[1] on how persisting email templates for
>> different locale should be done. I am planning to follow a similar approach
>> in storing challenge questions for different locale. The idea explained in
>> [1] is to store the template/question as a registry resource rather than as
>> a registry property. So I will be following a structure similar to shown
>> below to store the challenge questions.
>>
>>
>> ​
>> So each question will be stored following a 
>> */system/config/challenge-questions///
>> *convention as shown above. The first step is to reuse most of the email
>> templates registry persistence code and make it generic (provide an
>> interface) to retrieve any registry resource(eg: email templates, challenge
>> questions, ) based on locale. The next step is to abstract the retrieval of
>> resources logic to support retrieval of resources from a DB, API etc.
>>
>>
>> [1] http://mail.wso2.org/mailarchive/architecture/2015-May/020188.html
>>
>> Thanks,
>> Farasath Ahamed
>> Software Engineer,
>> WSO2 Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>
>
>
> --
> Kasun Bandara
> *Software Engineer*
> Mobile : +94 (0) 718 338 360
> <%2B94%20%280%29%20773%20451194>
> kas...@wso2.com <thili...@wso2.com>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS] User Challenge question Internationalization

[Farasath Ahamed]

Hi Omindu,

On Thu, Jun 9, 2016 at 1:29 AM, Omindu Rathnaweera <omi...@wso2.com> wrote:

> Hi Fara,
>
> A few questions.
>
> i. How is this going to work in user registration ? Will there be an API
> to retrieve a question set, given the locale?
>

Yes, we are going provide an API for retrieving challenge questions based
on locale.

>
> ii. Will we be needing a tenant specific config to set a default locale ?
>

IMO this will be useful for cases where the default locale is something
other than en_US (English-US) which we take as the default locale at the
moment. This is remove burden of having to add questions in English-US for
a tenant operating in a different locale than English-US.

>
> Having a default locale will be needed in a case like 'Ask password' where
> an admin initiates a user registration flaw. AFAIK the default locale is
> fixed to EN at the moment. So in that case a user will always receive the
> account creation email in EN. May be the challenge questions system too can
> benefit from such a config.
>
> iii. When we are supporting questions in multiple locales, is it necessary
> to have all the question in a set in each language ?
>

Say a user set his challenge question and answer in English. He switches to
Spanish later. If we want to support showing the challenge question in
Spanish rather than in English (originally set locale) then we would need
to have all the question in a set in each language. At the moment we are
discussing whether we need to support this.

>
>
> Regards,
> Omindu.
>
>
> On Sun, Jun 5, 2016 at 8:20 AM, Isura Karunaratne <is...@wso2.com> wrote:
>
>> Hi Farasath,
>>
>> Currently, we are using "http://wso2.org/claims/challengeQuestionUris "
>> claim to identity user answered challenge question set Ids. Following is a
>> sample value for that claim.
>>
>> *http://wso2.org/claims/challengeQuestion1!http://wso2.org/claims/challengeQuestion2
>> <http://wso2.org/claims/challengeQuestion1!http://wso2.org/claims/challengeQuestion2>.*
>>
>>
>> user answered challenge questions are stored in different claims as
>> follows.
>>
>> Claim URI : http://wso2.org/claims/challengeQuestion1
>> Value: City where you were born
>> ?!CCKWN1bOcOwXuJ3zPyThGZu3GZouQYGfw1tHWjUJdi4=
>>
>> Claim URI : http://wso2.org/claims/challengeQuestion2
>> Value: What is your first pet's name
>> ?!CCKWN1bOcOwXuJ3zPyThGZu3GZouQYGfw1tHWjUJdi4=
>>
>>
>> So, actual challenge question and encripted answer is stored as claim.
>> Since user may change his locale runtime, I think in new implementation we
>> have to store some question id rather than questoin text in claim.
>> Otherwise security question will display in previous locale.
>>
>> Other improvement that we can do here is to use json string to store
>> question set ids and claim values rather than seperating from a seperator
>> ("!")
>>
>> Thanks
>> Isura.
>>
>>
>>
>> On Sat, Jun 4, 2016 at 1:43 PM, Farasath Ahamed <farasa...@wso2.com>
>> wrote:
>>
>>> Hi Kasun,
>>>
>>> "isPromoteQuestion" property is no longer used in our current
>>> implementation. Therefore, we can get rid of the property and straight away
>>> persist the challenge question as a registry resource.
>>>
>>> Thanks,
>>>
>>> Farasath Ahamed
>>> Software Engineer,
>>> WSO2 Inc.; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>>
>>> Email: farasa...@wso2.com
>>> Mobile: +94777603866
>>> Blog: blog.farazath.com
>>> Twitter: @farazath619 <https://twitter.com/farazath619>
>>>
>>> On Sat, Jun 4, 2016 at 12:26 AM, Kasun Bandara <kas...@wso2.com> wrote:
>>>
>>>> Hi Farasath,
>>>>
>>>> +1 for storing the content of the questions as the registry resource
>>>> values. But how are you planning to store the boolean values such as "
>>>> *isPromoteQuestion*" ?. I think it's better to keep that sort of data
>>>> as a property value, so the retrieval process will be easy. WDYT ?
>>>>
>>>> Thanks,
>>>> Kasun.
>>>>
>>>> On Sat, Jun 4, 2016 at 12:16 AM, Farasath Ahamed <farasa...@wso2.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> In the current implementation, challenge questions are persisted to
>>>>> the registry as registry resource properties as shown below.
>>>>>
>>&

Re: [Architecture] [IS] DCR implementation

[Farasath Ahamed]

Hi Harsha,

When implementing User Managed Access 1.0 for WSO2 Identity Server, we
implemented a valve similar to what you have proposed here. You can find
the implemented tomcat valve here[1]. Since the endpoints implemented for
UMA were OAuth protected, the idea was to do the OAuth token validation at
the valve and pass the result to each endpoint by setting the token
validation response as an attribute in the request forwarded to the
endpoint.


[1]
https://github.com/mefarazath/carbon-identity/blob/gsoc-uma/components/tomcat-valve/src/main/java/org/wso2/carbon/identity/tomcat/valve/OAuthAccessTokenValidatorValve.java


Thanks,
Farasath Ahamed
Software Engineer,
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware


Email: farasa...@wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>

On Fri, Jun 17, 2016 at 1:12 AM, Harsha Thirimanna <hars...@wso2.com> wrote:

> Hi All,
>
> We have covered three [1], [2], [3] specification(not fully, but mostly
> used areas) with this feature.
>
> ​OAuth application registration and delete
> OIDC application registration.
>
> *Client Registration Request*
>
> To register a new Client at the Authorization Server, the Client sends an
> HTTP POST message to the Client Registration Endpoint with any Client
> Metadata parameters that the Client chooses to specify for itself during
> the registration. The Authorization Server assigns this Client a unique
> Client Identifier, optionally assigns a Client Secret, and associates the
> Metadata given in the request with the issued Client Identifier.
>
> *Sample Request*
>
> POST /identity/connect/register HTTP/1.1
> Content-Type: application/json
> Accept: application/json
> Host: server.example.com
>
> {
> "redirect_uris": ["server.example.com"],
> "client_name": "rest_api_store_1",
> "ext_param_owner": "admin",
> "grant_types": ["password"]
> }
>
>
> *Response*
>
> HTTP/1.1 201 Created
> Content-Type: application/json
> Cache-Control: no-store
> Pragma: no-cache
>
> {
> "client_id": "s6BhdRkqt3",
> "client_secret":
> "ZJYCqe3GGRvdrudKyZS0XhGv_Z45DuKhCUk0gBR1vZk",
> "client_secret_expires_at": 1577858400,
> "redirect_uris":
> ["server.example.com"],
> "client_name": "admin_rest_api_store_1"
> }
>
>
> *Error Response*
>
> HTTP/1.1 400 Bad Request
> Content-Type: application/json
> Cache-Control: no-store
> Pragma: no-cache
>
> {
> "error": "invalid_redirect_uri",
> "error_description": "One or more redirect_uri values are invalid"
> }
>
>
> *Client UnRegistration Request*
>
> To deprovision itself on the authorization server, the client makes
> an HTTP DELETE request to the client configuration endpoint.
> DELETE /identity/register/s6BhdRkqt3 HTTP/1.1
> Host: server.example.com
>
> Adding ‘client_id’ value as a url path variable.
>
>
> ​To implement this, we used our new framework implementation and oidc.dcr
> feature was extended by the oath.dcr feature.
>
> Now we have to implement an authentication layer for this and we are
> trying to implement it as a valve to make it common to our all the rest
> api's. But we have another concern, if we implemented like that, would it
> be a performance impact because all the request will go through that even
> though those are not belong to this context or not. If it is, then we can
> write it in generic way and front to the each rest api separately.
>
> In this case we have to think about the authorization model as well.
>
>
> ​[1] https://tools.ietf.org/html/rfc7591​
> ​[2] https://tools.ietf.org/html/rfc7592​
> [3] https://openid.net/specs/openid-connect-registration-1_0.html
>
> thanks
>
> *Harsha Thirimanna*
> Associate Tech Lead; WSO2, Inc.; http://wso2.com
> * <http://www.apache.org/>*
> *email: **hars...@wso2.com* <az...@wso2.com>* cell: +94 71 5186770 *
> *twitter: **http://twitter.com/ <http://twitter.com/afkham_azeez>*
> *harshathirimannlinked-in: **http:
> <http://lk.linkedin.com/in/afkhamazeez>**//www.linkedin.com/pub/harsha-thirimanna/10/ab8/122
> <http://www.linkedin.com/pub/harsha-thirimanna/10/ab8/122>*
>
> *Lean . Enterprise . Middleware*
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Implementing proper security model for dashboard server

[Farasath Ahamed]

Hi Suho,

Just to be clear, Are we going to use the Password Grant Type in the case
where SSO is disabled or is it the Client Credentials grant type using the
client_id and client_secret of the app created?


Thanks,
Farasath Ahamed
Software Engineer,
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware


Email: farasa...@wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 <https://twitter.com/farazath619>

On Thu, Apr 28, 2016 at 10:28 PM, Sriskandarajah Suhothayan <s...@wso2.com>
wrote:

> Thanks Sumedha for the points, to make life easy for the gadget developer
> we decided to add oAuth token retrieval to DS.
>
> Based on the offline discussion with Johann, Sinthuja and Geesara we
> decided to support only the following scenarios for DS
>
> 1. If SSO is enabled, obtaining a token (OAuth2) using SAML Token and
> passing to the backend
>
> 2. If SSO is disabled, obtaining a token (OAuth2) using client credential
> grant type and passing to the backend,
> Here the username and password will be obtained at server login and the
> token is generated at the same time.
>
> In both cases we will be using DCR for client registration at the server
> level, and same token will be used by all gadgets to access the secured
> backend APIs.
>
> To access secured backend from the gadgets a oAuth2Client js service (shindig
> features) will be implemented at DS, such that gadgets can talk to
> backend using the oAuth2Client which will embed appropriate authorisation
> header when sending.
>
> Regards
> Suho
>
> On Thu, Apr 28, 2016 at 2:37 PM, Sinthuja Ragendran <sinth...@wso2.com>
> wrote:
>
>> Hi Sumedha,
>>
>> On Thu, Apr 28, 2016 at 1:58 PM, Sumedha Rubasinghe <sume...@wso2.com>
>> wrote:
>>
>>> Geesara,
>>> This is a model that should be coming out of Dashboard perspective.
>>>
>>> If we take a look @ basic building blocks of DS, its (similar to what
>>> you have mentioned)
>>> - Gadget
>>> - Dashboard
>>> - Wizards
>>> - Dashboard Admin panel
>>> - etc
>>>
>>> Each of these elements should have a permission model associated per
>>> instance.
>>>
>>
>> Yeah +1, as per now the permission checks are not implemented for these
>> operations, but we need to incorporate that as well.
>>
>>
>>> For example, defining "permission to view any gadget" is not enough.
>>> But rather it should be "permission to view Gadget X".
>>> Same should be extended for all other building blocks. (AFAIK, this is
>>> not there for gadgets as of now)
>>>
>>> These need to be stored @ gadget server level and evaluated b4 rendering
>>> any gadget.
>>>
>>
>> Yeah, actually we are planning to implement the role based access control
>> for gadgets and then again different views of the dashboard page based on
>> roles.
>>
>>
>>>
>>> Permissions to BE
>>> 
>>> Once presentation layer permissions are sorted, it becomes
>>> responsibility of Gadget / Dashboard author to figure out mapping
>>> those permissions to a backend API.
>>>
>>> There are multiple ways to do this based on how backend is secured.
>>> - Passing session cookie obtained @ login to backend
>>> - Obtaining a token (OAuth2) using session cooking (using an OAuth2
>>> grant type)
>>> - If SSO is enabled, obtaining a token (OAuth2) using SAML Token
>>> - IdP enabled deployment
>>>
>>> Ensuring backend API's permission requirements match front end user's
>>> privileges is part of author's
>>> responsibility. This is not something DS product needs to worry about.
>>>
>>
>> Exactly, but I think there should be some API provided by DS server
>> (shindig features), so that the users can just call the necessary methods
>> with respective parameters to get oauth token. WDYT?
>>
>> Thanks,
>> Sinthuja.
>>
>>
>>> If by any chance backend is written using WSO2 technologies, we can
>>> leverage concepts like
>>> - Sharing same identity provider for both DS and BE server
>>> - passing authorisation details from FE to BE using JWT/SAML Response /
>>> User profile
>>>
>>>
>>> Permissions when gadgets being embedded into other products without
>>> dashboard
>>> 
>>> This is yet another perspe

Re: [Architecture] [IS] Block brute force attacks on password recovery flows

[Farasath Ahamed]

Hi Thanuja,


On Mon, Jun 20, 2016 at 1:35 PM, Thanuja Jayasinghe 
wrote:

> Hi All,
>
> I'm working on $subject.
>
> We are planning to prevent this flow from brute force attacks by enabling
> followings,
>
>1. Enable captcha/reCaptcha after n failed attempts
>2. Lock the account after n failed attempts for a period of time
>
> How are we going to keep track of this "period of time" after an account
is locked?


> *How to track failed attempts?*
>
> We already have a "http://wso2.org/claims/identity/failedLoginAttempts; claim
> which used in the login flow to track failed login attempts. Since this is
> a different flow, using the same claim to track the failed password reset
> attempts will lead to unintended situations. (Ex: After n number of
> failed attempts in the login flow, a user may try to reset the password. In
> this case, the user will see captcha if the number of failed attempts
> reached to the maximum. But since this is the first time which the user
> tries to reset the password, captcha is redundant.)
>
> So we will introduce a new claim call "
> http://wso2.org/claims/identity/failedPasswordResetAttempts; to track
> this.
>
>
> *Implementation*
>
> *Enable captcha/reCaptcha after n failed attempts* -  New Captcha
> connector will introduce to handle this. The configuration of the connector
> UI will allow modifying connector according to the requirements.
>
> *Lock the account after n failed attempts for a period of time *- Account
> lock will handle from the identity recovery rest API logic. Also 
> "PRE_SET_USER_CLAIMS"
> and "POST_SET_USER_CLAIMS" events will be reused to send notifications in
> case of account lock.
>
> Appreciate your input.
>
> Thanks,
> Thanuja
>
> --
> *Thanuja Lakmal*
> Senior Software Engineer
> WSO2 Inc. http://wso2.com/
> *lean.enterprise.middleware*
> Mobile: +94715979891 +94758009992
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
Thanks,
Farasath.
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS 6.0.0] Email Management Component Implementation

[Farasath Ahamed]

On Sun, Jan 22, 2017 at 3:10 AM, Lahiru Manohara  wrote:

> Hi,
>
> We are implementing email management component for IS 6.0.0. The following
> properties will be included in the email template.
>
> configuration:
>  -
>   subject:
>   body:
>   footer:
>   type:
>   display:
>   locale:
>   emailContentType:
>
> The following directory structure will be used to keep the template based
> on the locale.
>
> config/
> └── email/
> ├── en_US
> │└── email-admin-config.yaml
> └── en_GB
> └── email-admin-config.yaml
>
>
Currently the structure we have is,

config/
└── email/
├── scenario1 (like AccountRecovery)

 └── en_US (here we have the actual template)

 └── en_GB


With this structure it was easy to delete a template type easily,
Let's say you wanted to delete all AccountRecovery template types, you
simply delete the "scenario1" template folder.

But with the proposed structure this becomes a bit tricky IMO, you
need to iterate through all locales (folders) and then read the
email-admin-config.yaml and delete the specific type of templates.


Even if you want to delete say AccountRecovery template in en_US you
would have to read the email-admin-config.yaml and then delete the
specific template and save the file again.


Any specifc reasons for chosing this directory structure?




> Appreciate your suggestions on above design.
>
> Best Regards,
> --
> *Lahiru Manohara*
> *Software Engineer*
> Mobile: +94716561576
> WSO2 Inc. | http://wso2.com
> lean.enterprise.middleware
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5][IS] IS 6.0 SP/IDP configuration file restructuring

[Farasath Ahamed]

On Feb 15, 2017 9:50 PM, "Harsha Thirimanna" <hars...@wso2.com> wrote:


On Wed, Feb 15, 2017 at 10:54 PM, Ishara Karunarathna <isha...@wso2.com>
wrote:

>
>
> On Thu, Feb 9, 2017 at 1:22 PM, Harsha Thirimanna <hars...@wso2.com>
> wrote:
>
>>
>>
>> On Thu, Feb 9, 2017 at 12:52 PM, Farasath Ahamed <farasa...@wso2.com>
>> wrote:
>>
>>> In the sample.yaml Service Provider configuration I noticed that we have
>>> SAML related SP configurations in two sections "requestHandlerConfigs" and
>>> "responseHandlerConfigs".
>>>
>>> Do we need this separation? Is there any advantage of decoupling request
>>> and response related configurations related to an Inbound Protocol like
>>> SAML or OAuth2?
>>>
>>>
>> ​I felt , it doesn't make sense to configure response configuration
>> within request configs.​ And there may be custom protocol that can be one
>> in request config and few  response config select based on conditions. I
>> meant, if we give this way, it would be more flexible that we give it
>> within one. WDYT ?
>>
> I will go with Farasaths suggestion, And I think it will complicate the
> common cases and would be a bad user experience. for example if some one
> configure a SAML base SP he will confused where to put what. better to be
> in a single configuration.
>

​Yes Ishara, I agree with you.  We can change it if it is confuse to do the
configuration. ​
But still we have two handlers to handle the inbound request and response
that is targeting to decouple the protocol bind. Because in standard
protocol, it is not definitely change the inbound request protocol and
response protocol. Because of that we can keep single config for both.
But when we write custom protocol to handle request response, it may be
changed the selecting of response handler based on current context
parameters and we have to let them for each and every response handlers to
keep their configs with himself and not force to get it from inbound
request handler configs.


I think it's fine for us to have this seperation in our implementation
level. But in configs we should hide this complexity as much as possible.

The most common case when some configures an inbound protocol say SAML they
expect the request and response both in the same protocol. Therefore most
natural way is to configure everything related to SAML in one place.

Therefore IMO let's make request/response handler config opaque to the end
user configuring the SP etc.


But still I agree with you to keep one config from request side to handle
both configs for request and response for standard protocol(SAML) what we
offer if you feel that it would be confused to the developers. I would like
to get others feedback also for this.

@*Prabath*, WDYT ?

>
> -Ishara
>
>>
>>
>>
>>>
>>> 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 Wed, Feb 8, 2017 at 11:02 AM, Darshana Gunawardana <darsh...@wso2.com
>>> > wrote:
>>>
>>>> +1 for this approach in general...
>>>>
>>>> On Thu, Feb 9, 2017 at 12:04 AM, Harsha Thirimanna <hars...@wso2.com>
>>>> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> Since we are moving to file base deployment for sp/idp, we have to
>>>>> create these files using yaml. While doing that we thought to resolve some
>>>>> issues and generalize the sp/idp files.
>>>>> As we have now in IS 5.3.0, we configure local authenticator in SP and
>>>>> federated authenticator in IDP file.
>>>>>
>>>>
>>>> But just to clarify the earlier behaviour in IS 5.x.x versions, no;
>>>> it's not define local authenticator configs in SP.. rather we associate
>>>> local authenticators to the SP.. The issue we had was, there is no way to
>>>> configure local authenticators from the UI.. In IS 5.3.0 we provided a way
>>>> to generate UI elements to resident IdP section, so someone need, they can
>>>> write a new local authenticator and configure it from the resident idp..
>>>>
>>>> Basically you propose the same approach for the IS 6.0.0 with the file
>>>> based configs..
>>>>
>>>> One improvement we can do is, rather than limiting to *idpName* and
>>>> *authenticat

Re: [Architecture] [C5][IS] IS 6.0 SP/IDP configuration file restructuring

[Farasath Ahamed]

In the sample.yaml Service Provider configuration I noticed that we have
SAML related SP configurations in two sections "requestHandlerConfigs" and
"responseHandlerConfigs".

Do we need this separation? Is there any advantage of decoupling request
and response related configurations related to an Inbound Protocol like
SAML or OAuth2?


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 Wed, Feb 8, 2017 at 11:02 AM, Darshana Gunawardana <darsh...@wso2.com>
wrote:

> +1 for this approach in general...
>
> On Thu, Feb 9, 2017 at 12:04 AM, Harsha Thirimanna <hars...@wso2.com>
> wrote:
>
>> Hi All,
>>
>> Since we are moving to file base deployment for sp/idp, we have to create
>> these files using yaml. While doing that we thought to resolve some issues
>> and generalize the sp/idp files.
>> As we have now in IS 5.3.0, we configure local authenticator in SP and
>> federated authenticator in IDP file.
>>
>
> But just to clarify the earlier behaviour in IS 5.x.x versions, no; it's
> not define local authenticator configs in SP.. rather we associate local
> authenticators to the SP.. The issue we had was, there is no way to
> configure local authenticators from the UI.. In IS 5.3.0 we provided a way
> to generate UI elements to resident IdP section, so someone need, they can
> write a new local authenticator and configure it from the resident idp..
>
> Basically you propose the same approach for the IS 6.0.0 with the file
> based configs..
>
> One improvement we can do is, rather than limiting to *idpName* and
> *authenticatorName* parameters in *authenticatorConfig*, allow it to pass
> any additional parameters to IdP (from that SP) so we won't ended up with
> the need of multiple resident idp to adequate different service providers
> requirements.
>
>
>> But it doesn't make sense to specially treat to the local authenticator
>> in SP side and we can consider it also as another idp.
>>
> We can name it as resident-idp and SP authenticator can point the idp name
>> when it want to use local one as same as it use federated one.
>> We can keep other resident identity provider configuration like password
>> policies, login policies, etc.. in separate config file that is decouple
>> with the outbound authentication flow.
>>
>
> What about provisioning configurations? where does that configs going to
> be in.. If the file name going to be *resident-idp* then all the
> configurations should be in that file when IS acting as a IdP.
>
> WDYT?
>
> Regards,
> Darshana.
>
>
>> This will not effect for the existing framework implementation but only
>> change the user experience that is more cleaner than now. I have attached
>> the sample sp file, sample idp file and resident idp file with this, it
>> would be great if i can get more feedbacks about this.
>>
>> thanks
>>
>> *Harsha Thirimanna*
>> *Associate Tech Lead | WSO2*
>>
>> Email: hars...@wso2.com
>> Mob: +94715186770 <+94%2071%20518%206770>
>> 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>
>>
>
>
>
> --
> Regards,
>
>
> *Darshana Gunawardana*Associate Technical Lead
> WSO2 Inc.; http://wso2.com
>
> *E-mail: darsh...@wso2.com <darsh...@wso2.com>*
> *Mobile: +94718566859 <+94%2071%20856%206859>*Lean . Enterprise .
> Middleware
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS] Authorization for Service Providers

[Farasath Ahamed]

We also need to consider how we are going to handle the 'NotApplicable' and
'Indeterminate' responses by the XACML engine. Especially the Indeterminate
response that might be due to some missing attributes etc.

AFAIK the decisions of multiple evaluated policies are currently evaluated
based on the combining algorithm (like Deny overrides, First applicable)
defined globally.
Shouldn't we also allow this algorithm to be decided at SP level?



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 Wed, Oct 19, 2016 at 1:20 AM, Pulasthi Mahawithana <pulast...@wso2.com>
wrote:

> Hi All,
>
> As per the current implementation of the Identity Server's authentication
> framework, it does not provide any OOTB authorization mechanism for the
> service providers. We are going to provide this capability to Identity
> server so that the users can be authorized to service providers using rules
> based on user attributes, userstore, time of the day, etc.
>
> Following is the proposed sequence for the implementation.
>
>
> [image: Inline image 1]
>
>
> The existing authentication flow is kept as is until the authentication
> steps are completed and authentication result decided. At the
> AuthenticationRequestHandler (after authentication) if the authentication
> is success, we will be calling an AuthorizationHandler with the
> authentication context. AuthenticationHandler is responsible for evaluating
> the configured policies and responding back whether the user is authorized
> or not. If the authorization is not required or handled by the SP
> itself, we'll be providing the capability of bypassing the authorization
> step per service provider .
>
> The default implementation of the AuthorizationHandler will be using the
> IS's XACML engine for authorization. It will send a XACML request to the
> PDP and the request will be evaluated against the policies published to the
> PDP. Admins can write XACML policies and publish them to allow/deny the
> users logging into SPs based on those policies.
>
> Also, to retrieve the basic authentication context values (such as SP
> Name, authenticated user's username/userstore/tenant) we will provide a
> default PIP. In case any complex or derived attributes are needed we can
> retrieve them by writing a custom PIP and use them in the policies.
>
> Please share your thoughts and suggestions.
>
> --
> *Pulasthi Mahawithana*
> Senior Software Engineer
> WSO2 Inc., http://wso2.com/
> Mobile: +94-71-5179022
> Blog: http://blog.pulasthi.org
>
> <https://wso2.com/signature>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[Farasath Ahamed]

Tested the following on the Identity Server 5.3.0-RC3 pack,

   - Create Service Provider by importing SAML metadata file.
   - Export Resident IDP metadata.
   - SAML SSO for apps hosted on Apache2 using mod_auth_mellon with
   Identity Server.
   - Verify CSRF protection for dashboard apps.
   - Verify IDENTITY- <https://wso2.org/jira/browse/IDENTITY->
   - Verify IDENTITY-5563 <https://wso2.org/jira/browse/IDENTITY-5563>
   - Recover Password with user locale based challenge questions.
   - Add User account association between two local user accounts.

 [+] Stable - go ahead and release


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 Fri, Jan 6, 2017 at 10:06 PM, Pulasthi Mahawithana <pulast...@wso2.com>
wrote:

> Hi All,
>
> This is the 3rd Release Candidate of WSO2 Identity Server 5.3.0.
>
> Please download, test the product and vote. Vote will be open for 72 hours
> or as needed.
>
> This release fixes the following issues:
>
> Runtime : https://wso2.org/jira/issues/?filter=13612
> Analytics : https://wso2.org/jira/issues/?filter=13614
>
> Source and distribution
>
> Run-time : https://github.com/wso2/product-is/releases/tag/v5.3.0-rc3
> Analytics : https://github.com/wso2/analytics-is/releases/tag/v5.3.0-
> rc3
>
> Please vote as follows.
> [+] Stable - go ahead and release
> [-] Broken - do not release (explain why)
>
> Thanks,
> - WSO2 Identity Server Team -
>
> --
> *Pulasthi Mahawithana*
> Senior Software Engineer
> WSO2 Inc., http://wso2.com/
> Mobile: +94-71-5179022 <+94%2071%20517%209022>
> Blog: http://blog.pulasthi.org
>
> <https://wso2.com/signature>
>
> ___
> Dev mailing list
> d...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM] [C5] Single sign on support in API Manager 3.0

[Farasath Ahamed]

On Thursday, March 30, 2017, Sajith Kariyawasam <saj...@wso2.com> wrote:

>
> When discussing about possible ways of implementing SSO for API Manager
> 3.0 (C5) we came up with following two approaches,
> In API Manager 3.0, store, publisher and admin apps will be Oauth clients,
> which works with access tokens.
>
> 1. Access token retrieved via SAML grant
>
> - When a user requests a resource, SAML client in the backend will create
> a SAML request and forwards to IDP
> - Once the user logged in to IDP,  SAML response will be sent back to the
> client.
> - SAML response will be then validated and if successful user will be
> logged into the app.
> - Exchange the SAML token to an access token
>
>
> ​
>
> 2. Access token retrieved via Authorization code grant
>
> When a user requests a resource, if he is not authenticated he will be
> redirected to the Authorization server.
> Then user provides username / pwd there and will get an authorization code.
> Then that authorization code is used to obtain the access token and use
> that access token in subsequent calls.
>
>
> Therefore it seems that, there is no real need of using SAML here,
> and implementation wise its much simpler to use 2nd approach as there
> won't be any dependencies for SAML libraries like we had in C4.
>
> Appreciate your thoughts in this
>


I am bit confused by this diagram :)

If I understood correctly, in OIDC flow diagram above the Resource
Server(or rather the OAuth client) would be either Publisher, Store or
Admin portal and the client is something like an agent like browser.

Based on the usual OIDC flow,
Then in step B, the user will be directed to IDP and upon authentication
will get the authorization code(not an access token?) in step D.

Thereafter the resource server usually does a backend call to get the
actual id_token that contain user attributes plus an access token too.

Step E would be the call to userinfo endpoint with the access token get the
user attributes.

In the above diagram in step B the client(browser agent) receives an
authorization code. Can you please explain how this happens?



> ​
> Image reference : https://www.mutuallyhuman.co
> m/blog/2013/05/09/choosing-an-sso-strategy-saml-vs-oauth2/
>
>
> Thanks,
> Sajith
>
> --
> Sajith Kariyawasam
> *Associate Tech Lead*
> *WSO2 Inc.; http://wso2.com <http://wso2.com/>*
> *Committer and PMC member, Apache Stratos *
> *AMIE (SL)*
> *Mobile: 0772269575*
>


-- 
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>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5][IS 6.0.0]Admin Forced Password Reset Via Offline for Existing Users

[Farasath Ahamed]

On Wednesday, March 15, 2017, Dilan Udara Ariyaratne 
wrote:

>
> On Tue, Mar 14, 2017 at 11:08 AM, Gayan Gunawardana  > wrote:
>
>>
>>
>> On Tue, Mar 14, 2017 at 10:58 AM, Hasanthi Purnima Dissanayake <
>> hasan...@wso2.com >
>> wrote:
>>
>>> Hi all,
>>>
>>> We are in the process of implementing Admin Forced Password Reset via
>>> Offline for existing users in Admin Portal for the new IS 6.0.0 release.
>>> The wireframe design for the UI is found at [1].
>>>
>>> Admin can select a user and generate a password for the selected user.
>>> This generated password is an OTP.
>>>
>>> This OTP is:
>>> 1. Not adhere to any password policy.
>>> 2. There is no validity period
>>> 3. Once this OTP is used it expires.
>>> 4. Not considered like a normal password and we are going to store it in
>>> IDN_RECOVERY_DATA table.
>>>
>> If admin generates two or more OTPs, what is the behavior ?
>> All valid or last one valid ?
>> Suppose there is two and we consume only first one, in that case does it
>> invalidate second one ?
>>
>
> Why should we allow multiple OTPs for a particular user at a given time ?
> Cannot we keep only one valid OTP for a user at a given time and override
> it at the point of creating a new one ?
>

I too have the same concern. What is the idea behind allowing multiple OTPs
at any point of time? Isn't the usual practice to keep only the latest OTP
active?



>
>>> [1] https://github.com/wso2-dev-ux/product-is/blob/master/Wirefr
>>> ames/admin-portal/v3/3.32%20%20Reset%20password%20with%20off
>>> line%20OTP%20-%20password%20generated.png
>>>
>>> Thanks,
>>>
>>> Hasanthi Dissanayake
>>>
>>> Software Engineer | WSO2
>>>
>>> E: hasan...@wso2.com 
>>> M :0718407133| http://wso2.com 
>>>
>>
>>
>>
>> --
>> Gayan Gunawardana
>> Software Engineer; WSO2 Inc.; http://wso2.com/
>> Email: ga...@wso2.com 
>> Mobile: +94 (71) 8020933
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> 
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>

-- 
*A.Farasath Ahamed*
Software Engineer | WSO2 Inc.
Mobile: +94 777 603 866
Blog: blog.farazath.com
E-Mail: mefaraz...@gmail.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM] [C5] Single sign on support in API Manager 3.0

[Farasath Ahamed]

On Sat, Apr 1, 2017 at 11:27 AM, Bhathiya Jayasekara <bhath...@wso2.com>
wrote:

>
>
> On Sat, Apr 1, 2017 at 1:39 AM, Farasath Ahamed <farasa...@wso2.com>
> wrote:
>
>>
>>
>> On Thursday, March 30, 2017, Sajith Kariyawasam <saj...@wso2.com> wrote:
>>
>>>
>>> When discussing about possible ways of implementing SSO for API Manager
>>> 3.0 (C5) we came up with following two approaches,
>>> In API Manager 3.0, store, publisher and admin apps will be Oauth
>>> clients, which works with access tokens.
>>>
>>> 1. Access token retrieved via SAML grant
>>>
>>> - When a user requests a resource, SAML client in the backend will
>>> create a SAML request and forwards to IDP
>>> - Once the user logged in to IDP,  SAML response will be sent back to
>>> the client.
>>> - SAML response will be then validated and if successful user will be
>>> logged into the app.
>>> - Exchange the SAML token to an access token
>>>
>>>
>>> ​
>>>
>>> 2. Access token retrieved via Authorization code grant
>>>
>>> When a user requests a resource, if he is not authenticated he will be
>>> redirected to the Authorization server.
>>> Then user provides username / pwd there and will get an authorization
>>> code.
>>> Then that authorization code is used to obtain the access token and use
>>> that access token in subsequent calls.
>>>
>>>
>>> Therefore it seems that, there is no real need of using SAML here,
>>> and implementation wise its much simpler to use 2nd approach as there
>>> won't be any dependencies for SAML libraries like we had in C4.
>>>
>>> Appreciate your thoughts in this
>>>
>>
>>
>> I am bit confused by this diagram :)
>>
>
> That's fair, because this diagram is drawn not to explain all the steps in
> OAuth2 flow, but to show that the SAML and OAuth2 flows are similar.
>
>
>>
>> If I understood correctly, in OIDC flow diagram above the Resource
>> Server(or rather the OAuth client) would be either Publisher, Store or
>> Admin portal and the client is something like an agent like browser.
>>
>> Based on the usual OIDC flow,
>> Then in step B, the user will be directed to IDP and upon authentication
>> will get the authorization code(not an access token?) in step D.
>>
>
> Actually all these happen in step A. Within step A, there is a call to to
> IDP, which authenticates and fetches the auth code. Then in step B, it is
> sent to the browser via a redirect.
>
> However, it doesn't look like the article in the image reference discusses
> about OIDC. Looks like the article is about just OAuth2. (Correct me if I'm
> missing anything here)
>
> Anyway, I'm +1 to have OIDC here.
>

Yeah I think it should be OIDC in any case, otherwise we can't get user
attributes from an access token introspection call (Unless the
Authorization Server sends custom claims) in Step E if we go by the OAuth2
flow.


>
> Thanks,
> Bhathiya
>
>
>>
>> Thereafter the resource server usually does a backend call to get the
>> actual id_token that contain user attributes plus an access token too.
>>
>> Step E would be the call to userinfo endpoint with the access token get
>> the user attributes.
>>
>> In the above diagram in step B the client(browser agent) receives an
>> authorization code. Can you please explain how this happens?
>>
>>
>>
>>> ​
>>> Image reference : https://www.mutuallyhuman.co
>>> m/blog/2013/05/09/choosing-an-sso-strategy-saml-vs-oauth2/
>>>
>>>
>>> Thanks,
>>> Sajith
>>>
>>> --
>>> Sajith Kariyawasam
>>> *Associate Tech Lead*
>>> *WSO2 Inc.; http://wso2.com <http://wso2.com/>*
>>> *Committer and PMC member, Apache Stratos *
>>> *AMIE (SL)*
>>> *Mobile: 0772269575 <077%20226%209575>*
>>>
>>
>>
>> --
>> 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>
>>
>>
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Bhathiya Jayasekara*
> *Associate Technical Lead,*
> *WSO2 inc., http://wso2.com <http://wso2.com>*
>
> *Phone: +94715478185 <+94%2071%20547%208185>*
> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
> <http://www.linkedin.com/in/bhathiyaj>*
> *Twitter: https://twitter.com/bhathiyax <https://twitter.com/bhathiyax>*
> *Blog: http://movingaheadblog.blogspot.com
> <http://movingaheadblog.blogspot.com/>*
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] IS Authentication Flow Behavior Between Multiple Service Providers

[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 Sat, Jul 15, 2017 at 11:35 AM, Johann Nallathamby <joh...@wso2.com>
wrote:

>
>
> On Sat, Jul 15, 2017 at 5:55 AM Darshana Gunawardana <darsh...@wso2.com>
> wrote:
>
>> Hi Johann,
>>
>> On Fri, Jul 14, 2017 at 5:45 PM Johann Nallathamby <joh...@wso2.com>
>> wrote:
>>
>>> Can we change the implementation as follows:
>>>
>>> If user is going to login to application Y, which has steps 1 to *m*,
>>> and user has already logged into Y
>>>
>> Should be corrected as application X?
>>
>
> Yes :)
>
>
>> which has steps 1 to *n*,
>>>
>> given p <= m , n
>>> User is already authenticated to step *p* of application Y, if user has
>>> logged in from any of the optional IdPs in step *p*, within the
>>> sequence of application X, between steps *p* and n*.*
>>>
>>
>> Anyway I don't think above algorithm is correct because it base on number
>> of steps.
>>
>> 1. The simple way of fixing this is handle LOCAL idp specially.
>>
>> Currently the framework calculates to bypass the step p (when loging to
>> app Y), if user have already logged in at least one of optional IdP in
>> previous login (app X).
>>
>> We have to add extra level of validation if the previously authenticated
>> IdP picked as the LOCAL IdP where it should check the whether previously
>> authenticated authenticator (basic authenticator) and current available
>> authenticator (TOTP) same or not.
>>
>> If it's not same, prompt for authentication without bypassing.
>>
>
> +1. This is also a good idea.
>

Shouldn't we do the same for Federated IDPs as well?
I mean we can configure multiple federated authenticators within the same
Fed IDP and then use each authenticator in different steps. This would be a
similar situation to the LOCAL IDP case right?


>
>
>> 2. The generic way of fixing this is, consider ACR for each IdP
>>
>> Extending the previous solution, (rather having special checks for LOCAL
>> IdP), check on the authentication level / ACR of the  any IdP when it
>> decide whether user already logged in with that IdP.
>>
>
> I believe that is the solution coming with IS 5.5.0.
>
>>
>> WDYT?
>>
>> Regards,
>>
>>
>>> Can we do something like this for 5.4.0? IMO this will be more practical
>>> and step up authentication will work seamlessly.
>>>
>>> Regards,
>>> Johann.
>>>
>>> On Fri, Jul 14, 2017 at 10:58 AM, Ishara Karunarathna <isha...@wso2.com>
>>> wrote:
>>>
>>>> Hi Johan,
>>>>
>>>> On Fri, Jul 14, 2017 at 1:56 PM, Johann Nallathamby <joh...@wso2.com>
>>>> wrote:
>>>>
>>>>> Hi Asela,
>>>>>
>>>>> On Fri, Jul 14, 2017 at 9:34 AM, Asela Pathberiya <as...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Jul 14, 2017 at 11:31 AM, Harsha Kumara <hars...@wso2.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> This is regarding the behavior of Authentication flow between
>>>>>>> multiple service providers.
>>>>>>>
>>>>>>> I have created two service providers with following configurations.
>>>>>>>
>>>>>>> *SP1*
>>>>>>>
>>>>>>> This service provider has two options which allow to users to login
>>>>>>> either Basic Authentication scheme or Facebook
>>>>>>>
>>>>>>> Configuration
>>>>>>>
>>>>>>> 1 Authentication Step with MultiOption with Basic Auth and Facebook.
>>>>>>>
>>>>>>>
>>>>>>> *SP2*
>>>>>>>
>>>>>>> This service provider has two authentication steps which allow to
>>>>>>> users to login either Basic Authentication scheme or Facebook and second
>>>>>>> authentication step with TOTP.
>>>>>>>
>>>>>>> Configuration
>>>>>>>
>>>>>>> 2 Authentication Steps
>>>>>>>
>>

Re: [Architecture] Validate Authorization headers for Oauth endpoints

[Farasath Ahamed]

On Tue, May 2, 2017 at 1:48 AM, Manoj Gunawardena  wrote:

> +1 for handle authorization in consistent way for all end points.
> Such as
> "/oauth2/introspect"
> "oauth2/userinfo"
>
> According to IS 5.3 Authentication and Authorization of REST APIS
> mechanism [1], what are the permission strings assign for following end
> points.
>
> "oauth2/token"
> "oauth2/revoke"
> "/oauth2/introspect"
> "oauth2/userinfo"
>


Of these, I think only "/oauth2/introspect" is currently protected with [1].







/permission/admin/manage/identity/applicationmgt/delete



/permission/admin/manage/identity/applicationmgt/create



*/permission/admin/manage/identity/applicationmgt/view*


/permission/admin/manage/identity/pep




Based on [2], AFAIU these are the required permissions,

"oauth2/token" -->  No permission check

"oauth2/revoke" --> /permission/admin/manage/identity/applicationmgt/view

"oauth2/userinfo" -->  No permission check


> [1] https://docs.wso2.com/display/IS530/Authenticating+and+
> Authorizing+REST+APIs
>

[2]
https://github.com/wso2-extensions/identity-inbound-auth-oauth/blob/master/components/org.wso2.carbon.identity.oauth/src/main/resources/META-INF/services.xml


>
>
> On Wed, Apr 26, 2017 at 3:50 PM, Johann Nallathamby 
> wrote:
>
>> How about "/oauth2/introspect" endpoint?
>>
>> On Wed, Apr 26, 2017 at 9:25 AM, Harsha Thirimanna 
>> wrote:
>>
>>> On Wed, Apr 26, 2017 at 9:07 AM, Asela Pathberiya 
>>> wrote:
>>>


 On Tue, Apr 25, 2017 at 3:34 PM, Harsha Thirimanna 
 wrote:

>
>
> On Tue, Apr 25, 2017 at 3:04 PM, Asela Pathberiya 
> wrote:
>
>>
>>
>> On Tue, Apr 25, 2017 at 2:52 PM, Harsha Thirimanna 
>> wrote:
>>
>>>
>>> On Tue, Apr 25, 2017 at 2:00 PM, Asela Pathberiya 
>>> wrote:
>>>


 On Tue, Apr 25, 2017 at 12:44 PM, Harsha Thirimanna <
 hars...@wso2.com> wrote:

>
> On Tue, Apr 25, 2017 at 12:38 PM, Nuwan Dias 
> wrote:
>
>> Hi Gayan,
>>
>> What are you trying to achieve by moving the client-secret
>> validation logic to the interceptor from the jax-rs layer?
>>
>
> ​Actually, we have separate layer to pass the secured API in IS
> and it is common service that can be used for any product. AppManager 
> also
> using that.
> In here also Gayan is trying to get the security check into that
> common layer instead of allowing to go into the next level to validate
> headers.  ​
>

 Are we going to use common basic authentication handler  ?

>>>
>>> ​This feature is already done in IS 5.3.0 as a common point to
>>> handle authentication and authorization per resources as in [1].​
>>>
>>> [1] http://harshathirimanna.blogspot.com/2016/11/authenticat
>>> ion-authorization-common.html
>>>

 BTW;  Client credentials can be received as url param..  Are we
 validating them in here ?  If it is not;  Why are we introducing two
 validation points for same ?

 ​If we have our own way to pass authentication details,​ then we
>>> have to write an authentication handler to that and register.
>>>
>>
>> This is according to the OAuth2 spec...  It meant that we need
>> another handler implementation to do it or can we use existing
>> authentication handler ?
>>
>
> ​What i meant was that we can write custom handler as well to here. ​
>
 Yes.  if it is;  it must be shipped by default.

>>> ​Gayan will do that with this implementation. ​
>>>


>
>
>
>>
>>
>>>
>>>
>>>
 Actually I do not see much use of changing the current validation
 model.

>>> ​This is for all the APIs in IS to handle
>>> authentication/authorization in common way​ and decouple it with
>>> implementation of each.
>>>
>>
>>>
>>>

 Thanks,
 Asela.


>
>
>
>> Since both run on the same JVM, doesn't the overhead of the
>> process remain the same, irrespective of where it runs?
>>
>> Thanks,
>> NuwanD.
>>
>> On Tue, Apr 25, 2017 at 12:27 PM, Gayan Gunawardana <
>> ga...@wso2.com> wrote:
>>
>>> Hi All,
>>>
>>> In Oauth /token endpoint and /revoke endpoint
>>>
>>> https://localhost:9443/oauth2/token
>>> https://localhost:9443/oauth2/revoke
>>>
>>> required authorization with client key, client 

[Architecture] Distinguish between local and federated users in oauth tables

[Farasath Ahamed]

;>>>> *USER_DOMAIN*,USER_TYPE,TOKEN_SCOPE_HASH,
>>>>>>
>>>>>>TOKEN_STATE,TOKEN_STATE_ID)
>>>>>>
>>>>>> What will be the places we will make use of the knowledge of
>>>>>> authenticated IDP?
>>>>>>
>>>>>>>
>>>>>>> -Ishara
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks & regards,
>>>>>>>> -Prabath
>>>>>>>>
>>>>>>>> On Tue, May 16, 2017 at 7:23 AM, Pushpalanka Jayawardhana <
>>>>>>>> la...@wso2.com> wrote:
>>>>>>>>
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> We have below 3 issues that are caused mainly because we don't
>>>>>>>>> have a clear way to distinguish local and federated users in oauth 
>>>>>>>>> related
>>>>>>>>> tables (authorization code and access token storage).
>>>>>>>>> There are few more issues related to sending subject claim in
>>>>>>>>> proper format in IDtoken, that needs to identify the user as 
>>>>>>>>> federated or
>>>>>>>>> local.
>>>>>>>>>
>>>>>>>>> In order to address these issues  we need to check whether user is
>>>>>>>>> from a federated IDP. To fix this without having DB schema changes, 
>>>>>>>>> IsharaK
>>>>>>>>> came up with this idea to use 'UserStoreDomain' column,
>>>>>>>>> to store the value 'FEDERATED' as user store domain for tokens and
>>>>>>>>> authorization codes issued to federated users. The relevant 
>>>>>>>>> authenticators
>>>>>>>>> and grant handlers are responsible to set 'isFederatedUser' flag to 
>>>>>>>>> true,
>>>>>>>>> whenever they are creating and passing an authenticated user to
>>>>>>>>> messageContext. OAuth storage will read and store it as the 
>>>>>>>>> userStoreDomain
>>>>>>>>> value with 'FEDERATED'. This domain is never expected to be sent out 
>>>>>>>>> from
>>>>>>>>> server as a user attribute or property or as part of username.
>>>>>>>>>
>>>>>>>>> In order to avoid any conflicts, we will avoid users from creating
>>>>>>>>> user store domains with the name 'FEDERATED'.
>>>>>>>>> If you see any pitfalls with this approach, please raise. We are
>>>>>>>>> proceeding with implementation as above.
>>>>>>>>>
>>>>>>>>> [1] - https://wso2.org/jira/browse/IDENTITY-5939
>>>>>>>>> [2] - https://wso2.org/jira/browse/IDENTITY-4880
>>>>>>>>> [3] - https://wso2.org/jira/browse/IDENTITY-4512
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> --
>>>>>>>>> Pushpalanka.
>>>>>>>>> --
>>>>>>>>> Pushpalanka Jayawardhana, B.Sc.Eng.(Hons).
>>>>>>>>> Senior Software Engineer, WSO2 Lanka (pvt) Ltd;  wso2.com/
>>>>>>>>> Mobile: +94779716248
>>>>>>>>> Blog: pushpalankajaya.blogspot.com/ | LinkedIn:
>>>>>>>>> lk.linkedin.com/in/pushpalanka/ | Twitter: @pushpalanka
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Thanks & Regards,
>>>>>>>> Prabath
>>>>>>>>
>>>>>>>> Twitter : @prabath
>>>>>>>> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena
>>>>>>>>
>>>>>>>> Mobile : +1 650 625 7950 <%28650%29%20625-7950>
>>>>>>>>
>>>>>>>> http://facilelogin.com
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Ishara Karunarathna
>>>>>>> Associate Technical Lead
>>>>>>> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>>>>>>>
>>>>>>> email: isha...@wso2.com,   blog: isharaaruna.blogspot.com,
>>>>>>> mobile: +94717996791 <071%20799%206791>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Pushpalanka.
>>>>>> --
>>>>>> Pushpalanka Jayawardhana, B.Sc.Eng.(Hons).
>>>>>> Senior Software Engineer, WSO2 Lanka (pvt) Ltd;  wso2.com/
>>>>>> Mobile: +94779716248
>>>>>> Blog: pushpalankajaya.blogspot.com/ | LinkedIn: lk.linkedin.com/in/p
>>>>>> ushpalanka/ | Twitter: @pushpalanka
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Thanks & Regards,
>>>>> Prabath
>>>>>
>>>>> Twitter : @prabath
>>>>> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena
>>>>>
>>>>> Mobile : +1 650 625 7950 <(650)%20625-7950>
>>>>>
>>>>> http://facilelogin.com
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Ishara Karunarathna
>>>> Associate Technical Lead
>>>> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>>>>
>>>> email: isha...@wso2.com,   blog: isharaaruna.blogspot.com,   mobile:
>>>> +94717996791 <071%20799%206791>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Thanks & Regards,
>>> Prabath
>>>
>>> Twitter : @prabath
>>> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena
>>>
>>> Mobile : +1 650 625 7950 <(650)%20625-7950>
>>>
>>> http://facilelogin.com
>>>
>>
>>
>>
>> --
>> Ishara Karunarathna
>> Associate Technical Lead
>> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>>
>> email: isha...@wso2.com,   blog: isharaaruna.blogspot.com,   mobile:
>> +94717996791 <071%20799%206791>
>>
>>
>>
>
>
> --
> Thanks & Regards,
> Prabath
>
> Twitter : @prabath
> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena
>
> Mobile : +1 650 625 7950
>
> http://facilelogin.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>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Force Delete Identity Providers

[Farasath Ahamed]

Another aspect to think when we delete an IDP would be the associated user
accounts to that IDP[1].  I think we can also show the number of affected
user accounts (user accounts that are associated with the IDP we are
deleting) in the warning screen as proposed by Malithi.

I too think it would be better to have a discussion on this to identify all
the cases that will be affected by IDP deletion and decide on the best
approach to handle them.


[1] https://docs.wso2.com/display/IS530/Associating+User+Accounts

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, May 19, 2017 at 10:05 AM, Malithi Edirisinghe <malit...@wso2.com>
wrote:

>
>
> On Fri, May 19, 2017 at 9:19 AM, Ishara Karunarathna <isha...@wso2.com>
> wrote:
>
>>
>>
>> On Fri, May 19, 2017 at 1:15 AM, Malithi Edirisinghe <malit...@wso2.com>
>> wrote:
>>
>>> Hi All,
>>>
>>> So in order to support force delete an identity provider, we have to
>>> first identify the places the respective identity provider can be referred
>>> and then we need to decide on the options we have, on removing those
>>> references.
>>> Basically, an identity provider is referred by a service provider in
>>> authentications steps and/or as a outbound provisioning connector. So I
>>> think we can have below options.
>>>
>>> 1. In authentication steps
>>> - If the respective IdP is the only step being configured
>>> Here we can simply remove it and set the local and outbound config of
>>> default SP (Even when there's no local and outbound config the default SP
>>> config is being picked).
>>> - If IdP is configured as a step among multiple authentication steps
>>> Here unless it's being specifically configured to be used to pick
>>> subject identifier or subject attributes, we can simply remove it. If it's
>>> configured to pick the subject identifier or attributes, we can follow a
>>> pattern like configuring the immediate step to pick the identifier or
>>> attributes. So, if it's the last, start from first step.
>>> - If IdP is configured as multi option in any step
>>> Here we can simply remove it, so the step will have only rest of the
>>> options
>>>
>>> 2. In outbound provisioning
>>> Here we can simply remove the reference of the IdP as a outbound
>>> provisioning connector.
>>> Yet, whatever we do, it should be upon confirmation of the user to force
>>> delete and the way the IdP is removed from SP references should be properly
>>> recorded in audit logs. In addition, I think it's better if we can notify
>>> the user on which SPs are affected and some info with that regard.
>>> Also, when asking for the confirmation from user to force delete, it
>>> would be better if can indicate how many SPs are getting affected.
>>> So at the moment we restrict the IdP deletion by checking for references
>>> with [1]. So I think we can simply introduce a similar method to the
>>> service API, that checks the SPs being referenced, to be invoked when
>>> requesting confirmation. Then upon confirmation deletion can be performed
>>> as above.
>>>
>> I think its hard to provide a generic, Customers may have different
>> usecases and customization around this. Automatically deleting them can be
>> a risk.
>> Even if we delete them automatically customers may have to go back and
>> modify SP configurations accordingly.
>>
>>
> It's the customers decision to force delete or not. We can highlight the
> consequences. As I said above, it's important to record the SPs effected
> and how they are effected. IMO, we should generate some report and notify.
> So that, if someone decide to force delete, before proceeding, he knows
> that it's getting effected to the SPs configured and the consequences and
> after performing he knows who are effected and what he may have to
> reconfigure.
>
>
>>
>>
>>
>>>
>>> [1]  https://github.com/wso2/carbon-identity-framework/blob/mast
>>> er/components/idp-mgt/org.wso2.carbon.idp.mgt/src/main/java/
>>> org/wso2/carbon/idp/mgt/dao/IdPManagementDAO.java#L1759
>>>
>>> Thanks,
>>> Malithi.
>>>
>>> On Thu, May 18, 2017 at 1:22 PM, Prabath Siriwardena <prab...@wso2.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Thu, May 18, 2017 at 12:09 AM, Ishara Karunarathna <ish

Re: [Architecture] Why we use timestampSkew default value as 300 seconds in identity.xml, why not 0 seconds.

[Farasath Ahamed]

On Wed, May 31, 2017 at 12:28 PM, Thanuja Jayasinghe 
wrote:

> Hi Dinali,
>
> Consider the following calculation.
>
> expiry time = issuedTimeInMillis + validityPeriodMillis -
> (System.currentTimeMillis() - timestampSkew)
>
> So actually token is valid for (validityPeriodMillis + timestampSkew)
> seconds. This additional time is added to avoid the error occurred due to
> the time synchronization issues between servers.
>
> If your servers are perfectly synced then you can use timestampSkew value
> as 0.
>

If we do not have any reasoning behind this 300s value the shouldn't our
default value be 0 as Dinali has suggested?


> Thanks,
> Thanuja
>
>
> On Wed, May 31, 2017 at 12:01 PM, Dinali Dabarera  wrote:
>
>> Hi All,
>>
>> In our identity.xml the default timeStampScrew value is used as 300
>> seconds. Shouldn't this be 0 seconds?
>>
>> Because when we are getting a token from password grant type again and
>> again *without a time delay*, the expiry time of the token
>> increases than its accepted value because of this equation we are using.
>>
>> expiry time = issuedTimeInMillis + validityPeriodMillis - (System.
>> currentTimeMillis() - timestampSkew);
>>
>> Since timestampSkew = 300 seconds, validityPeriodMillis = 3600 seconds,
>> therefore, expiry time = 3644 seconds which can not be happened.
>>
>> Therefore, it is better to have the default timeStampScrew value as 0
>> seconds in order to get correct results.
>>
>>
>> Thanks!
>>
>> --
>> *Dinali Rosemin Dabarera*
>> Software Engineer
>> WSO2 Lanka (pvt) Ltd.
>> Web: http://wso2.com/
>> Email : gdrdabar...@gmail.com
>> LinkedIn 
>> Mobile: +94770198933 <+94%2077%20019%208933>
>>
>>
>>
>>
>> 
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
> --
> *Thanuja Lakmal*
> Associate Technical Lead
> WSO2 Inc. http://wso2.com/
> *lean.enterprise.middleware*
> Mobile: +94715979891
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Validate Authorization headers for Oauth endpoints

[Farasath Ahamed]

On Tue, May 2, 2017 at 9:55 AM, Manoj Gunawardena <man...@wso2.com> wrote:

> If permission check not provided, is it allow to all?
> Any reason for token and user info end points hasn't check permissions?
>


OAuth token endpoint, client has to authenticate using client_id ,
client_secret.
As for the userinfo endpoint it's open AFAIK.



>
>
> On Tue, May 2, 2017 at 3:02 AM, Farasath Ahamed <farasa...@wso2.com>
> wrote:
>
>>
>>
>>
>> On Tue, May 2, 2017 at 1:48 AM, Manoj Gunawardena <man...@wso2.com>
>> wrote:
>>
>>> +1 for handle authorization in consistent way for all end points.
>>> Such as
>>> "/oauth2/introspect"
>>> "oauth2/userinfo"
>>>
>>> According to IS 5.3 Authentication and Authorization of REST APIS
>>> mechanism [1], what are the permission strings assign for following end
>>> points.
>>>
>>> "oauth2/token"
>>> "oauth2/revoke"
>>> "/oauth2/introspect"
>>> "oauth2/userinfo"
>>>
>>
>>
>> Of these, I think only "/oauth2/introspect" is currently protected with
>> [1].
>>
>> 
>> > http-method="all"/>
>> > secured="true" http-method="all"/>
>> > http-method="all"/>
>> > http-method="all">
>> /permission/admin/manage/identity/applicationmg
>> t/delete
>> 
>> > secured="true" http-method="all">
>> /permission/admin/manage/identity/applicationmg
>> t/create
>> 
>> > http-method="all">
>> 
>> */permission/admin/manage/identity/applicationmgt/view*
>> 
>> > secured="true" http-method="all">
>> /permission/admin/manage/identity/pep> ons>
>> 
>> 
>>
>>
>> Based on [2], AFAIU these are the required permissions,
>>
>> "oauth2/token" -->  No permission check
>>
>> "oauth2/revoke" --> /permission/admin/manage/identity/applicationmgt/view
>>
>> "oauth2/userinfo" -->  No permission check
>>
>>
>>> [1] https://docs.wso2.com/display/IS530/Authenticating+and+Autho
>>> rizing+REST+APIs
>>>
>>
>> [2] https://github.com/wso2-extensions/identity-inbound-auth
>> -oauth/blob/master/components/org.wso2.carbon.identity.oauth
>> /src/main/resources/META-INF/services.xml
>>
>>
>>>
>>>
>>> On Wed, Apr 26, 2017 at 3:50 PM, Johann Nallathamby <joh...@wso2.com>
>>> wrote:
>>>
>>>> How about "/oauth2/introspect" endpoint?
>>>>
>>>> On Wed, Apr 26, 2017 at 9:25 AM, Harsha Thirimanna <hars...@wso2.com>
>>>> wrote:
>>>>
>>>>> On Wed, Apr 26, 2017 at 9:07 AM, Asela Pathberiya <as...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Apr 25, 2017 at 3:34 PM, Harsha Thirimanna <hars...@wso2.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Apr 25, 2017 at 3:04 PM, Asela Pathberiya <as...@wso2.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Apr 25, 2017 at 2:52 PM, Harsha Thirimanna <
>>>>>>>> hars...@wso2.com> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Apr 25, 2017 at 2:00 PM, Asela Pathberiya <as...@wso2.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Apr 25, 2017 at 12:44 PM, Harsha Thirimanna <
>>>>>>>>>> hars...@wso2.com> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Apr 25, 2017 at 12:38 PM, Nuwan Dias <nuw...@wso2.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Gayan,
>>>>>>>>>>>>
>&g

Re: [Architecture] [IAM] Adding/Reloading X509 Certificates at Runtime without Restart

[Farasath Ahamed]

+1
I think this is a MUST have feature if are to move the IS runtime into
cloud.

Think about a scenario where we need to import Service Provider public
certificates for SAML Authentication request validation. If we do not
support reloading keystore dynamically we need to restart everynode
everytime we do a cert upload.

We can't afford to restart the nodes everytime we upload a SP cert in a
cloud environment.

On Friday, October 6, 2017, Sanjeewa Malalgoda <sanje...@wso2.com> wrote:

> +1. We are seeing this limitation in API Manager as well. It would be
> great if we can have this feature ASAP.
>
> Thanks,
> sanjeewa.
>
> On Sat, Sep 9, 2017 at 11:57 AM, Johann Nallathamby <joh...@wso2.com
> <javascript:_e(%7B%7D,'cvml','joh...@wso2.com');>> wrote:
>
>> Hi IAM Team,
>>
>> The current keystore management functionalities of Carbon Server are
>> provided by the security-mgt bundle. The features include,
>>
>>- Adding new key stores
>>- Adding/Removing certificates to key stores (including the carbon
>>server default key store)
>>
>> For the admin user the UI displays the carbon server key store
>> (wso2-carbon.jks by default). The certificates and private key in this key
>> store is used to sign and verify SSO requests etc. Additionally the server
>> comprises of a trust store (client-truststore.jks by default) that is used
>> to verify hosts (much like a web browser verifies websites) - this trust
>> store is used during processes like OpenID Connect to verify the identity
>> of authorization server etc.
>>
>> Current Limitations include:
>>
>>- Client-truststore.jks is not displayed on the UI - so if one needs
>>to add certificates to the trust store one will have to do it externally
>>[1].
>>- There is no option to add additional trust stores - only key stores
>>that includes a private key are allowed to be added.
>>- In order for the changes to take effect the server needs to be
>>restarted. [1]
>>
>> As the solution we have to:
>>
>>- Alter UI to view the default trust store
>>- Alter keystore management service to support the addition of trust
>>stores
>>- Create a X509TrustManager implementation that dynamically reloads
>>any changes made to the trust store. Anyone using this
>>"DynamicX509TrustManager" with SSLContext will not require to restart the
>>server for changes to client trust store to take effect.
>>
>> Above changes were made on pull request [2].
>>
>> Why we couldn't merge this feature earlier was that we hadn't developed a
>> solution to sync this change from node to all nodes in the cluster. At the
>> time of this development our syncing mechanism was primarily svn based
>> deployment synchronization. However now we recommend deployment
>> synchronization as the last option. Our preferred options are NFS file
>> mount and r-sync. In such cases syncing is taken care by the
>> infrastructure. So this solution seems to be good enough. This is the same
>> case with secondary user stores as well.
>>
>> Although this use case is more prevalent in products such as ESB or API
>> Manager, in IS I see following use cases.
>>
>> 1. Connecting to a LDAP backend via over SSL.
>> 2. Connecting to a HTTP backend over SSL/TLS. E.g. OpenID Connect Token
>> Endpoint call
>> 3. Provisioning connectors (SCIM, DuoSecurity, etc.)
>> 4. Connecting to 3rd party SMS services. E.g. Nexmo.
>>
>> Is this something we see valuable that can be added to IS 5.4.0 or 5.5.0?
>>
>> [1] https://wso2.org/jira/browse/IDENTITY-1131
>> [2] https://github.com/wso2/carbon-identity/pull/1511
>>
>> Thanks & Regards,
>> Johann.
>>
>> --
>>
>> *Johann Dilantha Nallathamby*
>> Senior Lead Solutions Engineer
>> WSO2, Inc.
>> lean.enterprise.middleware
>>
>> Mobile - *+9476950*
>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
>>
>
>
>
> --
>
> *Sanjeewa Malalgoda*
> WSO2 Inc.
> Mobile : +94713068779
>
> <http://sanjeewamalalgoda.blogspot.com/>blog :http://sanjeewamalalgoda.
> blogspot.com/ <http://sanjeewamalalgoda.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>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[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: [Architecture] WSO2 IS : what are the differences between OpenID Connect & OAuth 2.0 federated authenticators

[Farasath Ahamed]

On Friday, December 15, 2017, Youcef HILEM <youcef.hi...@laposte.fr> wrote:

> Hi Hasanthi,
>
> Yes I know that the password grant is supported .
>
> My question is: can I use the password grant with our third party IDP OAuth
> 2.0 [3] just integrated with [2].


No. We do not support password grant type in our OAuth/OIDC federated
authenticator.

However, if you have a strong requirement to federate using password grant
type you can do so by extending the oauth/oidc authenticator. One thing to
keep in mind is that you might have to introduce and intermediate page to
prompt for credentials to be used in the password grant request.

As a user this means I am exposing my credentials at an intermediate
page(not at the trusted federated idp) which could be a security concerns.
Personally I would prefer the authorization code flow over password grant
flow to login using a third party idp.



>
>
> [1] Federated Authentication -
> https://docs.wso2.com/display/IS530/Federated+Authentication
> [2] Configuring OAuth2-OpenID Connect -
> https://docs.wso2.com/display/IS530/Configuring+OAuth2-OpenID+Connect
> [3] IBM Security Access Manager 9.0.3.1 - OAuth 2.0 endpoints -
> https://www.ibm.com/support/knowledgecenter/en/SSPREK_9.0.
> 3.1/com.ibm.isam.doc/config/concept/OAuthEndpoints.html#oauthendpoints
>
> Thanks
> Youcef HILEM
>
>
>
>
> --
> Sent from: http://wso2-oxygen-tank.10903.n7.nabble.com/WSO2-
> Architecture-f62919.html
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
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>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[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 *
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[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: d...@wso2.org
   - Architecture List: architecture@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>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[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: [Architecture] IS550: Oauth Role or XACML scope validation

[Farasath Ahamed]

On Friday, May 4, 2018, Vadim Kimlaychuk <vadim.kimlayc...@cooppank.ee>
wrote:

> Dear architects,
>
>   I am trying to implement validation for OAuth tokens described here
> : https://docs.wso2.com/display/IS560/Validating+the+Scope+of+
> OAuth+Access+Tokens+using+XACML+Policies. Since this example failed for
> me I have tried to do similar with role validation described here:
> https://docs.wso2.com/display/IS560/Configuring+Access+
> Control+Policy+for+a+Service+Provider. When none of them worked I started
> to investigate logs of the server and saw that none of validation seems to
> happen. Should I write down some module/class and register it to make it
> work or configuration through UI should be enough?
>
>   My test scenario with IS 5.5.0 and curl is following:
>
>1. Registered SP Playground2 with OAuth2/OpenID connect configuration.
>"Authorization", "SaaS",  "Role based scope validator" and "XACML Scope
>Validator" options are enabled
>2.  curl -u : -k -d 
> "grant_type=password=user=user1"
>-H "Content-Type:application/x-www-form-urlencoded"
>https://localhost:9443/oauth2/token
><https://localhost:9443/oauth2/token> works and I got access token
>3. Created PAP from auth_role_based_policy where user "user" is
>"denied" because he is not in a role. Checked it with "Try" -- works
>4. Published to PDP
>5. tried curl to issue new token -- token issued as before. No
>restriction for the user
>
>   May be I am using it in a wrong way?
>
> Thanks in advance,
>
> Vadim
>


-- 
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>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Conditional authentication - functions

[Farasath Ahamed]

On Mon, May 21, 2018 at 6:27 PM, Nilasini Thirunavukkarasu <
nilas...@wso2.com> wrote:

> Hi,
>
> I am going to introduce following APIs for script-based conditional
> authentication.
>
> 1. lockUserAccount(user)
>
>- locks the user account. Only the admin can unlock the account
>
> *Example:-  *If the user A has logged in from a different country, then
> User A's account can be locked using the above function.
>
>
> 2. enableUserAccount(user)
>
>- When the user account is in disable state admin can enable the user
>account using the above function.
>
>
> 3. getLocalUser(user,idp)
>
How about naming this function getAssociatedLocalUser(user, idp)? It gives
a better indication of what the function is meant for IMO


>
>- Get the local user. If it is a federation login, check whether the
>federated user is associated with a local user. If there is a user
>association then return the associated local user, if not return null.
>- Parameters:- user - federated user, idp - federated identity provider
>
> *Example:-  *UserA has an association in IS with his Facebook account. If
> the UserA logs in from facebook, his associated local account can be
> retrieved using above function.
>
>
> 4. associateUserAccount(localuser, fuser, fidp)
>
>- Associate the local user with the federated user.
>- Parameters:- fuser - federated user, fidp - federated identity
>provider
>
> *Example:- *If the user A has two accounts, an account in IS and an
> account on Facebook. We can use above function with the
> two-step authentication to associate those two accounts automatically.
>
>
> Any suggestions would be appreciated.
>
> Thanks,
> Nila.
>
>
> --
> Nilasini Thirunavukkarasu
> Software Engineer - WSO2
>
> Email : nilas...@wso2.com
> Mobile : +94775241823
> Web : http://wso2.com/
>
>
> <http://wso2.com/signature>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
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>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [RRT] Forcing the challenge question for Identity Server

[Farasath Ahamed]

On Tuesday, May 29, 2018, Rosen Silva  wrote:

> Hi All,
>
> I'm implementing a feature for IS 5.5.0 to force users to add answers to
> challenge questions.
> This feature is implemented using PostAuthenticationHandler.
>
>  The logic executes in the following order,
> * Check whether the user has already added the answers from the post
> authenticator
> * If not, redirect users to a webpage (JSP file) to get the answers to the
> challenge questions
> * Check whether users have added the challenge questions
> * Let users log in to sp if the user has filled the answers to challenge
> questions
>
>
> Clarifications with implementing the JSP page for retrieving and updating
> answers to challenge questions
>
> AFAIK we can't use admin service for retrieve and update security
> questions since we don't have the cookie while in the post-authentication
> flow.
> One possibility is to send the challenge questions to the webpage with the
> HTTP serverlet request and get the answers back to post authentication
> handler through serverlet response and add the answers to the challenge
> questions.
>
Can you explain how we plan to retrieve the available challenge questions
of the tenant in this approach?

>
> Your input is appreciated.
>
> Thanks and regards,
> --
>
> *Rosen Silva*
> Software Engineer - WSO2
>
> Email: ros...@wso2.com
> Mobile: +94770677418
> Web: https://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>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Handling custom claims when generating JWT token using JWT grant type

[Farasath Ahamed]

On Wed, May 30, 2018 at 4:04 PM, Megala Uthayakumar  wrote:

> Resending the missing image
>
>
>

Regarding "SP Claim Mapping exist with requested attributes" decision,
shouldn't this simply be SP requested claims since we do not care about SP
claim mapping in OIDC flow?


> ​​
>
> On Wed, May 30, 2018 at 4:02 PM, Megala Uthayakumar 
> wrote:
>
>> *Hi,*
>>
>> *As per the offline discussion with IAM team, following is the agreed
>> design.*
>>
>>
>>
>> *Darshana/Maduranga/Farasath/IAM Team - Please do correct me if I have
>> misunderstood regarding this.*
>>
>> *Thanks.*
>>
>> Regards,
>> Megala
>>
>> On Thu, May 24, 2018 at 9:41 AM, Megala Uthayakumar 
>> wrote:
>>
>>> Hi,
>>>
>>> As per the meeting held offline, it was decide to only send the custom
>>> claims when the scope is given as "openid". Sending custom claims that are
>>> not defined in dialect can be supported by adding new claims to openid
>>> dialect and by appending the relevant scopes to "/oidc" resource in config
>>> registry.
>>>
>>> Thanks.
>>>
>>> Regards,
>>> Megala
>>>
>>> On Wed, May 23, 2018 at 2:41 PM, Bhathiya Jayasekara 
>>> wrote:
>>>
>>>> Thanks, I just understood the scenario.
>>>>
>>>> Thanks,
>>>> Bhathiya
>>>>
>>>> On Wed, May 23, 2018 at 2:36 PM, Megala Uthayakumar 
>>>> wrote:
>>>>
>>>>> Hi Bhathiya,
>>>>>
>>>>> On Wed, May 23, 2018 at 1:05 PM, Bhathiya Jayasekara <
>>>>> bhath...@wso2.com> wrote:
>>>>>
>>>>>> Hi Megala,
>>>>>>
>>>>>> On Wed, May 23, 2018 at 10:11 AM, Megala Uthayakumar >>>>> > wrote:
>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> I am working on $subject for IS 5.5.0.
>>>>>>>
>>>>>>> When handling custom claims, we do have two options.
>>>>>>>
>>>>>>>1. Handling custom claims as we have handled it in the
>>>>>>>SAML2BearerGrantHandler.
>>>>>>>   - Current SAML2BearerGrantHandler converts the claims coming
>>>>>>>   from IDP to local claims and then filter out oidc claims only, 
>>>>>>> given that
>>>>>>>   scope is given as openid.
>>>>>>>   2. Handle relevant custom claims as it is when scope is not
>>>>>>>openid and if the scope is openid filter out the openid scopes as we 
>>>>>>> do for
>>>>>>>SAML2BearerGrantHandler
>>>>>>>   - If the scope is not openid, add all the custom claims with
>>>>>>>   the access token.
>>>>>>>   - If the scope is openid, follow the same approach followed
>>>>>>>   by SAML2BearerGrantHandler.
>>>>>>>
>>>>>>> I think option 2 is better way to handle this, becuase,
>>>>>>>
>>>>>>> JWT do not restrict the collection of custom claims, hence if we go
>>>>>>> with option 1, customer is expected to select one of the open id claims 
>>>>>>> to
>>>>>>> get his claims back in original incoming JWT.
>>>>>>>
>>>>>>
>>>>>> Could you please explain this line further?
>>>>>>
>>>>> In our wso2 IS server, we have predefined list of oidc claims[1], but
>>>>> in JWT we can have custom claims that are not defined in our list.
>>>>>
>>>>> For example,
>>>>> A thrid party identity provider may send a claim with the name
>>>>> "testClaim" with its JWT token and the service provider may expect the 
>>>>> same
>>>>> claim with the same name, but this cannot be done in our case, as we only
>>>>> pass the predefined set of oidc claims to service provider.
>>>>>
>>>>>
>>>>>> And in the subject you meant generating access token (but not JWT
>>>>>> token) right?
>>>>>>
>>>>> Self contained access token, which is a JWT token. [2]
>>>>>
>>>>>
>>>>>>
>>>>>> Thanks,
&g

Re: [Architecture] Handling custom claims when generating JWT token using JWT grant type

[Farasath Ahamed]

On Wed, May 30, 2018 at 4:17 PM, Megala Uthayakumar  wrote:

> Yes. I tried to explain the same thing, seems it is confusing. I will
> simplify it.
>

Thanks for the clarification.


>
> Thanks.
>
> Regards,
> Megala
>
> On Wed, May 30, 2018 at 4:12 PM, Farasath Ahamed 
> wrote:
>
>>
>>
>> On Wed, May 30, 2018 at 4:04 PM, Megala Uthayakumar 
>> wrote:
>>
>>> Resending the missing image
>>>
>>>
>>>
>>
>> Regarding "SP Claim Mapping exist with requested attributes" decision,
>> shouldn't this simply be SP requested claims since we do not care about SP
>> claim mapping in OIDC flow?
>>
>>
>>> ​​
>>>
>>> On Wed, May 30, 2018 at 4:02 PM, Megala Uthayakumar 
>>> wrote:
>>>
>>>> *Hi,*
>>>>
>>>> *As per the offline discussion with IAM team, following is the agreed
>>>> design.*
>>>>
>>>>
>>>>
>>>> *Darshana/Maduranga/Farasath/IAM Team - Please do correct me if I have
>>>> misunderstood regarding this.*
>>>>
>>>> *Thanks.*
>>>>
>>>> Regards,
>>>> Megala
>>>>
>>>> On Thu, May 24, 2018 at 9:41 AM, Megala Uthayakumar 
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> As per the meeting held offline, it was decide to only send the custom
>>>>> claims when the scope is given as "openid". Sending custom claims that are
>>>>> not defined in dialect can be supported by adding new claims to openid
>>>>> dialect and by appending the relevant scopes to "/oidc" resource in config
>>>>> registry.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Regards,
>>>>> Megala
>>>>>
>>>>> On Wed, May 23, 2018 at 2:41 PM, Bhathiya Jayasekara <
>>>>> bhath...@wso2.com> wrote:
>>>>>
>>>>>> Thanks, I just understood the scenario.
>>>>>>
>>>>>> Thanks,
>>>>>> Bhathiya
>>>>>>
>>>>>> On Wed, May 23, 2018 at 2:36 PM, Megala Uthayakumar 
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Bhathiya,
>>>>>>>
>>>>>>> On Wed, May 23, 2018 at 1:05 PM, Bhathiya Jayasekara <
>>>>>>> bhath...@wso2.com> wrote:
>>>>>>>
>>>>>>>> Hi Megala,
>>>>>>>>
>>>>>>>> On Wed, May 23, 2018 at 10:11 AM, Megala Uthayakumar <
>>>>>>>> meg...@wso2.com> wrote:
>>>>>>>>
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> I am working on $subject for IS 5.5.0.
>>>>>>>>>
>>>>>>>>> When handling custom claims, we do have two options.
>>>>>>>>>
>>>>>>>>>1. Handling custom claims as we have handled it in the
>>>>>>>>>SAML2BearerGrantHandler.
>>>>>>>>>   - Current SAML2BearerGrantHandler converts the claims
>>>>>>>>>   coming from IDP to local claims and then filter out oidc claims 
>>>>>>>>> only, given
>>>>>>>>>   that scope is given as openid.
>>>>>>>>>   2. Handle relevant custom claims as it is when scope is not
>>>>>>>>>openid and if the scope is openid filter out the openid scopes as 
>>>>>>>>> we do for
>>>>>>>>>SAML2BearerGrantHandler
>>>>>>>>>   - If the scope is not openid, add all the custom claims
>>>>>>>>>   with the access token.
>>>>>>>>>   - If the scope is openid, follow the same approach followed
>>>>>>>>>   by SAML2BearerGrantHandler.
>>>>>>>>>
>>>>>>>>> I think option 2 is better way to handle this, becuase,
>>>>>>>>>
>>>>>>>>> JWT do not restrict the collection of custom claims, hence if we
>>>>>>>>> go with option 1, customer is expected to select one of the open id 
>>>>>>>>> claims
>>>>>>>>> to get his claims back 

Re: [Architecture] SAML Artifact Binding - Server Side Implementations

[Farasath Ahamed]

t;> Best regards,
>>>> Vihanga.
>>>>
>>>> [1] - "[Architecture] [IAM] SAML Artifact Binding" @
>>>> architecture@wso2.org
>>>> [2] - https://www.oasis-open.org/committees/download.php/35387/
>>>> sstc-saml-bindings-errata-2.0-wd-05-diff.pdf
>>>> <https://www.google.com/url?q=https://www.oasis-open.org/committees/download.php/35387/sstc-saml-bindings-errata-2.0-wd-05-diff.pdf=D=hangouts=1529490475881000=AFQjCNG3_d5jo1kSGGuO9_TMVz2oNTswag>
>>>> --
>>>>
>>>> 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>
>>>
>>
>>
>> --
>>
>> 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>
>
> --
> 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>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] WSO2 Identity Server 5.4.0 Alpha6 Released!

[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: d...@wso2.org
   - Architecture List: architecture@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>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IAM] JWT client authentication for OAuth 2.0 for IS 5.5.0

[Farasath Ahamed]

On Friday, January 5, 2018, Hasanthi Purnima Dissanayake <hasan...@wso2.com>
wrote:

> Hi Isura/Omindu,
>
> Which data are supposed to store in  IDN_JWT_PRIVATE_KEY table? What is
>> the reason to store those data?
>>
>
> In the patch that we have provided for 5.3.0 , this table contains
> following fields.
> JWT_ID (primary key)
> EXP_TIME
> TIME_CREATED
>
> JWT_ID is an unique identifier for the token. According to the spec this
> token should not be reused. So JWT_ID is responsible for prevent re-use of
> this token. Hence we need to store the JWT_ID. Based on the EXP_TIME we
> have planned to clean the records. The spec is bit flexible on re-using
> the token.  So once the token is expired we let the same JWT_ID to be
> re-used.
>

Shouldn't this restriction per SP(client)?
Since jti is an identifier string, what happens if two different SPs send
two different JWTs with the same jti?


>
>
> jtiREQUIRED. JWT ID. A unique identifier for the token, which can be used
> to prevent reuse of the token. These tokens MUST only be used once, unless
> conditions for reuse were negotiated between the parties; any such
> negotiation is beyond the scope of this specification.
>
>
> If we are storing private keys in the table, make sure the content is
>> encrypted to avoid security concerns.
>
>
> Actually we don't store private keys here. Anyway the table name is bit
> misleading. So shall we re-name the table as IDN_OIDC_JTI?
>
>
> Thanks,
>
> On Fri, Jan 5, 2018 at 7:49 AM, Isura Karunaratne <is...@wso2.com> wrote:
>
>> Hi Hasanthi,
>>
>> On Thu, Jan 4, 2018 at 4:32 PM, Hasanthi Purnima Dissanayake <
>> hasan...@wso2.com> wrote:
>>
>>> Hi All,
>>>
>>> Following tasks are identified for the implementation for the $subject.
>>>
>>> 1. Move the logic of validating the token API invocation request to
>>> validate required parameters for JWT client authentication to
>>> PrivatekeyJWTClientAuthHandler
>>> 2. Introduce a new interface to read the public certificate.
>>>- Certificate can be read from keystore
>>>- Certificate can be read from db
>>>- Certificate can be read from any other means
>>> 3. Data which will be persisted in IDN_JWT_PRIVATE_KEY can be grown
>>> rapidly which may cause to some performance issues. So need to implement a
>>> cleanup script based on the expiration time of the JWT.
>>>
>>
>> Which data are supposed to store in  IDN_JWT_PRIVATE_KEY table? What is
>> the reason to store those data?
>>
>> Thanks
>> Isura.
>>
>>> 4. Honour the UI configuration for confidential applications which is
>>> discussed in mail [1]
>>>
>>> Apart from above need to consider on following tasks:
>>> 1. Improving the unit tests of the repository
>>> 2. Improve the documentations for the $subject.
>>>
>>>
>>> [1] Confidential Aplications in OAuth2 Flow
>>>
>>> Thanks,
>>> --
>>>
>>> Hasanthi Dissanayake
>>>
>>> Senior Software Engineer | WSO2
>>>
>>> E: hasan...@wso2.com
>>> M :0718407133| http://wso2.com <http://wso2.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/
>>
>>
>>
>>
>
>
> --
>
> Hasanthi Dissanayake
>
> Senior Software Engineer | WSO2
>
> E: hasan...@wso2.com
> M :0718407133| http://wso2.com <http://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>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Decoupling Client Authentication from OAuth2 Flow

[Farasath Ahamed]

On Mon, Jan 8, 2018 at 4:49 PM, Hasintha Indrajee  wrote:

> The idea behind this is to decouple the authentication mechanism used by
> OAuth2 clients from the rest of the OAuth2 logic, so that different types
> of client authenticators can be plugged. For an example according to
> specification [1] client_secret_basic, client_secret_post,
> client_secret_jwt are few client authentication mechanisms.
>
> The client authentication will be done through an extension. Hence
> different client authentication criteria can be implemented and can be
> plugged.
>
> The interface (API) will consist of three main methods.
>
> 1) canAuthenticate - Decides whether the particular authenticator can
> authenticate the incoming request or not.
>
> 2) authenticateClient - Authenticates the client request based on
> information present. As a result of authentication client ID will be
> available in the context.
>
> 3) getClientId - Depending on the authentication mechanism they way client
> ID is extracted depends. For an example in JWT client authentication client
> sends out the client Id within the JWT as the subject. Hence in a case
> authenticaiton fails, we may need to extract client Id for other puposes.
> ex - data publishing, if the client is non confidential.
>
> The client authenticator has to be implemented as an OSGI bundle and
> should be deployed in dropins upon building. Also relevant authenticator
> name has to be configured in identity.xml under client authenticators.
>
> 
>
>  ClientAuthHandler>
>
> 
>

Do we have any plan in future to facilitate defining client authenticators
per OAuth application (service provider)?
Also do we have a way to define an oauth application as non-confidential
using the UI or do we need to write a custom client authentication handler
to do so?

>
> [1] http://openid.net/specs/openid-connect-core-1_0.html#Cli
> entAuthentication
> 
>
>
>
>
>
>
> --
> Hasintha Indrajee
> WSO2, Inc.
> Mobile:+94 771892453 <077%20189%202453>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] OIDC request object support

[Farasath Ahamed]

gt; On Wed, Oct 11, 2017 at 4:35 PM, Hasanthi Purnima Dissanayake <
>>> hasan...@wso2.com> wrote:
>>>
>>>> Hi All,
>>>>
>>>> In order to support 'Request Object' we need to support two parameters.
>>>> 1. request parameter
>>>> 2. request_uri parameter
>>>>
>>>>
>>>>
>>>> *1. request_parameter*
>>>> The purpose of this parameter is for supporting to request some claims
>>>> other than the default Userinfo and IdToken claim set which is associated
>>>> with the requested scope.
>>>>
>>>> So if we consider a sample request with above parameter,
>>>>
>>>> https://localhost:9443/oauth2/authorize?
>>>> response_type=code%20id_token
>>>> _id=X
>>>> _uri=http://localhost:8080/playground
>>>> =openid
>>>> =af0ifjsldkj
>>>> =n-0S6_WzA2Mj
>>>> ={
>>>>   "iss": "s6BhdRkqt3",
>>>>   "aud": "https://server.example.com;,
>>>>   "response_type": "code id_token",
>>>>   "client_id": "s6BhdRkqt3",
>>>>   "redirect_uri": "https://client.example.org/cb;,
>>>>   "scope": "openid",
>>>>   "state": "af0ifjsldkj",
>>>>   "nonce": "n-0S6_WzA2Mj",
>>>>   "max_age": 86400,
>>>>
>>>>   "claims": {
>>>> "userinfo": {
>>>>   "given_name": {
>>>> "essential": true
>>>>   },
>>>>   "nickname": null,
>>>>   "email": {
>>>> "essential": true
>>>>   },
>>>>
>>>> "id_token": {
>>>>   "gender": null,
>>>>   "birthdate": {
>>>> "essential": true
>>>>   },
>>>>   "acr": {
>>>> "values": [
>>>>   "urn:mace:incommon:iap:silver"
>>>> ]
>>>>   }
>>>> }
>>>>   }
>>>> }
>>>>
>>>>
>>>> The expected behavior of Identity server will be as follows.
>>>>
>>>> 1.Consider the claims "given_name" and "email" which are marked as
>>>> 'essential:true' for 'userinfo' member. Even if they are not mapped with
>>>> the openid scope in the registry,  if these claims are requested claims,
>>>> then 'given_name' and 'email' will be returned from the Userinfo endpoint.
>>>> So as a summary the claims which have marked as 'essential : true' only get
>>>> controlled by the requested claims and ignore the requested scopes. If the
>>>> server can not provide those essential claims there wont be any failure or
>>>> error message returning from the server.
>>>>
>>>
>>> Is there any instance in which IS will throw error to client because it
>>> cannot send the claim?
>>>
>>> Because in the spec it says the following.
>>>
>>> Note that even if the Claims are not available because the End-User did
>>> not authorize their release or they are not present, the Authorization
>>> Server MUST NOT generate an error when Claims are not returned, whether
>>> they are Essential or Voluntary, unless otherwise specified in the
>>> description of the specific claim.
>>>
>>> So IMO we need to have a property for each claim that says whether we
>>> return an error or not.
>>>
>>> Wdyt?
>>>
>>>
>>>>
>>>> 2. The claims like "nickname" it will act as a default claim and will
>>>> control by both requested scopes and the requested claims.
>>>>
>>>
>>> What do you mean by controlling using requested scope? Do you mean if
>>> the client doesn't request at least one scope that includes this claim we
>>> won't return that claim? I don't think that is mentioned in the spec. Can
>>> you clarify?
>>>
>>> Regards,
>>> Johann.
>>>
>>>
>>>> This behavior is common to the id token as well.
>>>>
>>>>
>>>>
>>>> *2. request_uri parameter*
>>>> In this case the url will be a pre-registered url by the RP for use at
>>>> the OP. The reference which is pointed from the url will consist the
>>>> relevant jwt. The rationale behind returning claims will be same as the
>>>> above in the request parameter.
>>>>
>>>> As we are planning to provide the implementation as a 5.3.0 WUM update
>>>> the 'acr' implementation will be not available there. So if 'acr' value is
>>>> requested as an essential claim a pre-define value will be returned.
>>>>
>>>> Any suggestion or feedback on the above will be highly appreciated.
>>>>
>>>> Thanks,
>>>>
>>>> Hasanthi Dissanayake
>>>>
>>>> Software Engineer | WSO2
>>>>
>>>> E: hasan...@wso2.com
>>>> M :0718407133| http://wso2.com <http://wso2.com/>
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> *Johann Dilantha Nallathamby*
>>> Senior Lead Solutions Engineer
>>> WSO2, Inc.
>>> lean.enterprise.middleware
>>>
>>> Mobile: *+94 77 7776950*
>>> LinkedIn: *http://www.linkedin.com/in/johann-nallathamby
>>> <http://www.linkedin.com/in/johann-nallathamby>*
>>> Medium: *https://medium.com/@johann_nallathamby
>>> <https://medium.com/@johann_nallathamby>*
>>> Twitter: *@dj_nallaa*
>>>
>>
>>
>>
>> --
>>
>> Hasanthi Dissanayake
>>
>> Senior Software Engineer | WSO2
>>
>> E: hasan...@wso2.com
>> M :0718407133| http://wso2.com <http://wso2.com/>
>>
>
>
>
> --
>
> *Johann Dilantha Nallathamby*
> Senior Lead Solutions Engineer
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile: *+94 77 7776950*
> LinkedIn: *http://www.linkedin.com/in/johann-nallathamby
> <http://www.linkedin.com/in/johann-nallathamby>*
> Medium: *https://medium.com/@johann_nallathamby
> <https://medium.com/@johann_nallathamby>*
> Twitter: *@dj_nallaa*
>


-- 
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>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[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>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [New Feature]: Cross Protocol IDP initiated SSO flow

[Farasath Ahamed]

On Wed, Jul 18, 2018 at 7:27 AM, Johann Nallathamby  wrote:

> Hi Dinali,
>
> *"IdP initiated SSO"* is something we already support between WSO2 IS and
> service providers registered in WSO2 IS.
>
> The names I can suggest for this feature are:
> *1. "IdP initiated inbound federation"*
> *2. "Federated IdP initiated SSO"*
>
> And I have a question on why we decided to introduce a new inbound
> endpoint.
>
> From SAML PoV, redirecting from the federated IdP to the /samlsso endpoint
> of IS with a IdP initiated SSO request and writing a request path
> authenticator to validate the SAML or JWT assertion will also work right?
>

We do not have to write new request path authenticators. The SAML/OIDC
federated authenticator can validate the SAML/OIDC Response if it is
available in the initial request handled by the authenticator. So
implicitly they will work as request path authenticators as well.


>
> And in your diagram also as the last step you are anyway initiating
> another IdP initiated login request to the /samlsso endpoint if SAML is
> selected in the configuration.
>
> So what I understand is, the intension of introducing a new endpoint is to
> make this flow generic for any protocol right?
>
> That being said, OIDC doesn't anyway have an IdP initiated concept. I am
> struggling to understanding how this would work with OIDC a service
> provider. Would you care to explain?
>
> Regards,
> Johann.
>
> On Tue, Jul 17, 2018 at 10:18 PM Dinali Dabarera  wrote:
>
>> Hi Chinthana,
>>
>> On Tue, Jul 17, 2018 at 10:01 PM Chintana Wilamuna 
>> wrote:
>>
>>> Hi,
>>>
>>> I'm assuming if there was no tenantId then we default to super tenant?
>>>
>>
>> ​Yes we can do that. If the response we get does not contain any tenant
>> domain, we can consider it as carbon.super.
>>
>>
>>
>>> Also can we make the query param of the tenantId configurable?
>>>
>>
>> Do you mean like, provide a configuration to add the tenant domain,
>> similar to protocol configuration?​
>>
>>
>>> Another change on UI - since we're only supporting SAML and OIDC shall
>>> we make this field a drop-down instead of a text field?
>>>
>>
>> ​It would be nice to see some radio buttons instead of drop dows as we
>> have only two options. WDYT ?
>> ​
>>
>> Thanks!
>> Dinali
>>
>>
>> --
>> *Dinali Rosemin Dabarera*
>> Software Engineer
>> WSO2 Lanka (pvt) Ltd.
>> Web: http://wso2.com/
>> Email : gdrdabar...@gmail.com
>> LinkedIn <https://lk.linkedin.com/in/dinalidabarera>
>> Mobile: +94770198933
>>
>>
>>
>>
>> <https://lk.linkedin.com/in/dinalidabarera>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
> --
>
> *Johann Dilantha Nallathamby*
> Senior Lead Solutions Engineer
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile: *+94 77 7776950*
> LinkedIn: *http://www.linkedin.com/in/johann-nallathamby
> <http://www.linkedin.com/in/johann-nallathamby>*
> Medium: *https://medium.com/@johann_nallathamby
> <https://medium.com/@johann_nallathamby>*
> Twitter: *@dj_nallaa*
>



-- 
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>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] OIDC request object support

[Farasath Ahamed]

On Tuesday, January 23, 2018, Johann Nallathamby <joh...@wso2.com> wrote:

> Hi Farasath,
>
> On Tue, Jan 23, 2018 at 12:13 PM, Farasath Ahamed <farasa...@wso2.com>
> wrote:
>
>>
>>
>> On Tuesday, January 23, 2018, Johann Nallathamby <joh...@wso2.com> wrote:
>>
>>> Hi Hasanthi,
>>>
>>> On Tue, Jan 23, 2018 at 9:31 AM, Hasanthi Purnima Dissanayake <
>>> hasan...@wso2.com> wrote:
>>>
>>>> Hi Johann,
>>>>
>>>> Is there any instance in which IS will throw error to client because it
>>>>> cannot send the claim?
>>>>>
>>>>> Because in the spec it says the following.
>>>>>
>>>>> Note that even if the Claims are not available because the End-User
>>>>> did not authorize their release or they are not present, the Authorization
>>>>> Server MUST NOT generate an error when Claims are not returned, whether
>>>>> they are Essential or Voluntary, unless otherwise specified in the
>>>>> description of the specific claim.
>>>>>
>>>>> So IMO we need to have a property for each claim that says whether we
>>>>> return an error or not.
>>>>>
>>>>> Wdyt?
>>>>>
>>>>
>>>> What I understand from the above is, if a claim is marked as essential
>>>> or voluntary and if the server can not return the claim the flow should not
>>>> break and server should not throw an error if it is not specially specified
>>>> in the server side. In this scope we don't specify this from server side.
>>>> Though this is not a MUST we can add this as an improvement as it adds a
>>>> value.
>>>>
>>>
>>> So IIUC in any circumstance we don't send an error to client. Correct?
>>>
>>> Yes, we can add that property as an improvement.
>>>
>>>>
>>>>
>>>>>> 2. The claims like "nickname" it will act as a default claim and will
>>>>>> control by both requested scopes and the requested claims.
>>>>>>
>>>>>
>>>>> What do you mean by controlling using requested scope? Do you mean if
>>>>> the client doesn't request at least one scope that includes this claim we
>>>>> won't return that claim? I don't think that is mentioned in the spec. Can
>>>>> you clarify?
>>>>>
>>>>
>>>> The spec does not directly specify how should we treat for the Voluntary
>>>> Claim from the server side. So what we have planned to do is to honour the
>>>> scopes and server level requested claims when returning this claim.
>>>>
>>>
>>> IMO, because the spec doesn't say to do anything special on the OP side
>>> about not being able to release a particular claim (it says not to break
>>> the normal flow), there is nothing special we can differentiate between
>>> essential and voluntary claims. Only thing we may be able to do is, give a
>>> warning to user saying that if s/he doesn't approve an essential claim s/he
>>> won't be able to work with the application smoothly. We can't do anything
>>> beyond that right?
>>>
>>> When you say scopes which scopes are you referring to? Are they the
>>> requested scopes in the request or the defined scopes in the registry? I
>>> fail to understand what scopes have to do with claims in this case.
>>> Following is what I find in spec related to this.
>>>
>>> "It is also the only way to request specific combinations of the
>>> standard Claims that cannot be specified using scope values. "
>>>
>>> As I understand if the specific requested OIDC claim, is defined in the
>>> OIDC dialect, the user has a value for that claim and s/he has approved
>>> that claim for the RP, then we can send them to the RP, regardless of
>>> whether it is defined in scope or not. Otherwise we are contradicting the
>>> above statement right?
>>>
>>> Also regarding requested claims in service provider configuration, IIRC
>>> we used it as a way to control access to certain claims by service
>>> providers, which overrides the requested scopes and requested claims. *But
>>> that is only if the requested claims list is not empty in service provider
>>> configuration*. I.e. requested claims in service provider configuration
>>> must have at least 1 claim. Otherwise what will happen is f

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

[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
>>>>> Architecture@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
>>>> d...@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
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>> ___
>> Architecture mailing list
>> Architecture@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
> d...@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>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] Missing JSESSION cookie

[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
> d...@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>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS] JDBC based Configuration Store for WSO2 IS

[Farasath Ahamed]

On Wed, Oct 17, 2018 at 10:36 AM Tharindu Bandara 
wrote:

> Hi all,
>
> I have been working on the $subject as WSO2 IS need a common place to
> store configurations.
>

Can you give some examples for the types of configurations we plan to
manage with this endpoint?


>
> Above diagramme is a high-level, modularized view of $subject approach.
>
> I am working on the Configuration Management Endpoint. Below include the
> REST API for this.
>
> Name : WSO2 Identity Server Configuration Management Rest API
>
> Base URL : {tenant-domain}/api/identity/config-mgt/v1.0
>
> URL
>
> Method
>
> Body
>
> Description
>
> /configuration
>
> POST
>
> Tenant Configurations object
>
> Add configurations
>
> PUT
>
> Tenant Configurations object
>
> Add or Replace configurations
>
> PATCH
>
> Tenant Configurations object
>
> Update existing configurations
>
> GET
>
> -
>
> Retrieve configurations
>
> DELETE
>
> -
>
> Revoke configurations
>
> /configuration/{key}
>
> POST
>
> Configuration object
>
> Add the configuration
>
> PUT
>
> Configuration object
>
> Add or Replace the configuration
>
> PATCH
>
> Configuration object
>
> Update existing configuration
>
> GET
>
> -
>
> Retrieve the configuration
>
> DELETE
>
> -
>
> Revoke the configuration
>
> A path parameter named ‘key’ is used to identify a configuration.
>
> Path Parameter
>
> Description
>
> {key}
>
> Key of the configuration
>
> Two types of data objects are used for above REST API calls.
>
> Data object
>
> Model
>
> Tenant Configurations object
>
> Configuration object
>
>
> Let’s have a look at an example POST request to add the “email
> configuration” using WSO2 Identity Server Configuration Management Rest API.
>
> Method
>
> POST
>
> URL
>
> /api/identity/config-mgt/v1.0/configuration/email
>
> Body
>
>
> Please refer to the detailed REST API documentation for in-depth
> information[1]
> <https://app.swaggerhub.com/apis-docs/WSO8/wso-2_identity_server_configuration_management_rest_api/1.0.0>
> .
>
> Please note that naming in the API is not finalized yet.
>
> Your valuable comments and suggestions are highly appreciated.
>
>
> [1]
> https://app.swaggerhub.com/apis-docs/WSO8/wso-2_identity_server_configuration_management_rest_api/1.0.0
> <https://app.swaggerhub.com/apis-docs/WSO8/wso-2_identity_server_configuration_management_rest_api/1.0.0#/>
>
> Thanks,
>
> Tharindu.
> --
> *Tharindu Bandara*
> Software Engineer | WSO2
>
> Email : tharin...@wso2.com
> Mobile : +94 714221776
> web : http://wso2.com
> <https://www.google.com/url?q=http://wso2.com=D=151765338399=AFQjCNFggB4bSJTKmdqKcBV0VY9xx1ABKg>
>
> https://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>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Auth0 OpenID Connector for IS

[Farasath Ahamed]

Hi Nirubikaa,

Before we start implementing this connector can we try our generic OIDC
Federation connector[1] to talk to Auth0 and see if it works?
Ideally, if Auth0 is having a standard OIDC Endpoint then this should work
without any issues.

[1] https://docs.wso2.com/display/IS570/Configuring+OAuth2-OpenID+Connect

On Mon, Jan 7, 2019 at 2:53 PM Nirubikaa Ravikumar 
wrote:

> please find the image,
>
> On Mon, Jan 7, 2019 at 1:23 PM Nirubikaa Ravikumar 
> wrote:
>
>> Hi all,
>> I am planing to work on  "Auth0 OpenID Connector ". Please find the flow
>> diagram below:
>>
>>
>>
>>
>> In the flow of OpenID Connect,
>>
>> User sends a request to service provider, then the request is redirected
>> to the WSO2 IS .Then the WSO2 IS requests to get authorization code with
>> client credentials, and Openid scope. Then the Auth0 redirects to the
>> request with Authorization code.
>>
>> Then WSO2 IS requests Access token, to that Auth0 responses with the
>> Access token, An ID token is issued from the token endpoint in addition to
>> an Access token.
>>
>> WSO2 IS requests to get user info, And Auth0 can retrieve user
>> information from the ID token or Access token.
>>
>> Thanks.
>> --
>> R.Nirubikaa
>> Intern | WSO2
>> M: O779108852
>>
>>
>>
>
>
> --
> R.Nirubikaa
> Intern | WSO2
> M: O779108852
>
>
>


-- 
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>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IAM] Supporting Description and Internationalization for OAuth2 Scopes

[Farasath Ahamed]

On Mon, Jun 3, 2019 at 1:07 PM Hasanthi Purnima Dissanayake <
hasan...@wso2.com> wrote:

> Hi Johann,
>
> The OAuth2 scopes implementation in IS doesn't support providing a human
>> readable description that can be shown in to the end-user when providing
>> consent.
>
>
> The OAuth2 scopes already have a description, but the internationalization
> is not supported. I think this is needed for registered scopes only, not
> the custom scopes
>
What do we mean by custom scopes here?
Also does this mean all scopes need to be pre-registered at the scope
endpoint?

>
> +1 for the improvement.
>
> Thanks,
> Hasanthi
>
> On Mon, Jun 3, 2019 at 12:23 PM Johann Nallathamby 
> wrote:
>
>> The OAuth2 scopes implementation in IS doesn't support providing a human
>> readable description that can be shown in to the end-user when providing
>> consent. Just showing the scope names doesn't help the end-user to decide
>> whether to grant the scope or not.
>>
>> The description should also support internationalization as in challenge
>> questions.
>>
>>
>> [1] https://github.com/wso2/product-is/issues/5354
>>
>> Thanks & Regards,
>> Johann.
>>
>> --
>> *Johann Dilantha Nallathamby* | Associate Director/Solutions Architect |
>> WSO2 Inc.
>> (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com
>> [image: Signature.jpg]
>>
>
>
> --
>
> Hasanthi Dissanayake | Senior Software Engineer | WSO2 Inc.
> (m) +94718407133 | (w) +94112145345  | Email: hasan...@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>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[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
>> Architecture@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
> Architecture@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>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[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
>>>>>>>> d...@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
>>>>>>> d...@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
>>>>>> d...@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
>>>> d...@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
>>> d...@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
>> d...@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
> d...@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>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[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>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM] Multiple Key Manager support

[Farasath Ahamed]

On Tue, Apr 14, 2020 at 10:13 PM Tharindu Dharmarathna 
wrote:

> Hi All,
>
> We are going to implement Multiple Oauth provider support to WSO2 API
> Management. From this feature, dev portal users can create their Oauth
> Application on Pre-Defined OAuth providers.
>
> 1. Tenant Admin Create Oauth Provider from the Admin portal by providing
> OAuth provider details.
>
>- Client Registration endpoint
>- Introspection Endpoint
>- Scope Management Endpoint
>- Token Endpoint
>- Revoke Endpoint
>- Endpoint Security Details
>- Token Validation Regex.
>
> Just a suggestion, most OAuth/OIDC providers expose a .wellknown
configuration endpoint that gives some of these endpoints. For example,
https://accounts.google.com/.well-known/openid-configuration
Maybe we can support populating the URLs from using that endpoint as well
in addition to configuring manually.

2. Application developer creates the application defining the Oauth
> Provider type.
> 3. Application developer Generates the keys from UI.
>
>- Checks for the Consumer Key Generation can be done in the Specific
>Oauth Provider.
>-  Generate the Oauth App on Oauth Provider and retrieves the Oauth
>Application Details.
>
> 4. Application Developer Retrieves the Application details from the UI.
>
>- Check for the Oauth provider selected.
>- Retrieve the Oauth App details from the Respective OAuth Provider
>selected.
>
> 5. Generating Oauth Token
>
>- Token Generation call will directly proxy into the token endpoint of
>Respective Oauth Provider.
>
> 6. Validating the Token.
>
>- Generated Token from Oauth Providers contains a specific change
>related to the Token.
>- Before validating the token we checking the Token was resided to
>which Oauth provider by checking from the Token Validation Regex given.
>- Token get validate from elected Oauth Provider and then retrieve the
>information related to the Token.
>
> 7. Delete the Application
>
>- Oauth Application will remove from Respective Oauth Provider
>assigned.
>
>
> I appreciate any thoughts and feedback on this.
>

Also, some of the endpoints exposed by OAuth providers will be protected
with different auth mechanisms. How do we plan to handle this?


>
>
> Thanks
>
> *Tharindu Dharmarathna*Technical Lead
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
> mobile: *+94779109091*
> ___
> Architecture mailing list
> Architecture@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>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture